From ghc-devs at haskell.org Wed Nov 1 01:51:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 01:51:10 -0000 Subject: [GHC] #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms In-Reply-To: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> References: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> Message-ID: <058.4f34ea5375e145d544604786a43f9153@haskell.org> #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_run/T14218 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by saurabhnanda): Commenting to be notified of future discussion (is there a better way to do this?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 01:57:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 01:57:39 -0000 Subject: [GHC] #13772: Cannot put HasCallStack on instances In-Reply-To: <047.d360e3ed5517211c4a279da62bac67fe@haskell.org> References: <047.d360e3ed5517211c4a279da62bac67fe@haskell.org> Message-ID: <062.19279e8aba42e3cb5316bc368a425fe6@haskell.org> #13772: Cannot put HasCallStack on instances -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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 saurabhnanda): Commenting to be notified of future discussion. (is there a better way to do this?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 02:02:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 02:02:05 -0000 Subject: [GHC] #13372: Attach CallStack to IOError, add CallStack constraints to relevant functions in base In-Reply-To: <045.e8d5052962549532effd4485f8aa5560@haskell.org> References: <045.e8d5052962549532effd4485f8aa5560@haskell.org> Message-ID: <060.2d21de7f707fff33a5814fd03d330c0c@haskell.org> #13372: Attach CallStack to IOError, add CallStack constraints to relevant functions in base -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12096 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by saurabhnanda): Commenting to be notified of future discussion. (is there a better way to do this?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 02:04:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 02:04:39 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.17534d08571b68dd3e0a5652bb1960fd@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): > and because it would incur some runtime overhead Is there any doc/benchmark that quantifies this runtime overhead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 02:08:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 02:08:20 -0000 Subject: [GHC] #13285: Bug in GHC.Stack.callStack when used with sections In-Reply-To: <050.81951777fb2bcb194935732bc18dc469@haskell.org> References: <050.81951777fb2bcb194935732bc18dc469@haskell.org> Message-ID: <065.c683dd1225e4cac415ac5b2ed577c4c4@haskell.org> #13285: Bug in GHC.Stack.callStack when used with sections -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | deSigar/should_run/T13285 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by saurabhnanda): Commenting to be notified of future discussion. (is there a better way of doing this?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 02:41:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 02:41:19 -0000 Subject: [GHC] #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms In-Reply-To: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> References: <043.f10cc79e139bfbf6784c621461609c48@haskell.org> Message-ID: <058.f855f46ea346701110997b620cb8cf31@haskell.org> #14218: GHC.Stack.HasCallStack not compatible with constraint synonyms -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_run/T14218 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Commenting to be notified of future discussion (is there a better way to do this?) You can, under “change the ticket”, add yourself to the “subscribers” or “observers” or however it is called in English. And I am under the impression that since a few months, simply commenting on a post no longer subscribes you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 03:42:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 03:42:07 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.01597ff7356296c6f45f53f8f51d2534@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 bgamari): Well, the overhead may (nearly) disappear entirely if the function with the constraint is inlined. If not then you will pay the cost of an additional pointer argument and possibly a constructor allocation. Also, to subscribe to future changes in a ticket add yourself to the CC field. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 10:15:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 10:15:18 -0000 Subject: [GHC] #11298: Implicit call stack empty in instance declarations In-Reply-To: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> References: <047.eab5c810a3c4684688e2a4bb98536a85@haskell.org> Message-ID: <062.d78138776108c10762587d084708e6b3@haskell.org> #11298: Implicit call stack empty in instance declarations -------------------------------------+------------------------------------- Reporter: pikajude | Owner: (none) 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 result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by saurabhnanda): * cc: saurabhnanda (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 10:19:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 10:19:38 -0000 Subject: [GHC] #11573: Inferred CallStacks expose implicit parameter In-Reply-To: <046.50bedf0c81dd2bc801447c1bb4cd0177@haskell.org> References: <046.50bedf0c81dd2bc801447c1bb4cd0177@haskell.org> Message-ID: <061.ac081b09bb9364afd8c2826e8470fe21@haskell.org> #11573: Inferred CallStacks expose implicit parameter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gridaphobe Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11383 | Differential Rev(s): Phab:D1911, Wiki Page: | Phab:D1912 -------------------------------------+------------------------------------- Changes (by saurabhnanda): * cc: saurabhnanda (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 10:21:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 10:21:23 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.a9de989cbff74557dc15afb1d42ab0fe@haskell.org> #12096: Attach stacktrace information to SomeException -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13372 | Differential Rev(s): Wiki Page: | Exceptions/StackTraces | -------------------------------------+------------------------------------- Changes (by saurabhnanda): * cc: saurabhnanda (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 10:21:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 10:21:34 -0000 Subject: [GHC] #11787: Infer HasCallStack where possible In-Reply-To: <046.5318fdb9ba2ad3000bcf4a93628510e1@haskell.org> References: <046.5318fdb9ba2ad3000bcf4a93628510e1@haskell.org> Message-ID: <061.c449ac36e449bbd50bdce7a7493d29b2@haskell.org> #11787: Infer HasCallStack where possible -------------------------------------+------------------------------------- Reporter: simonpj | Owner: gridaphobe Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 saurabhnanda): * cc: saurabhnanda (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 10:22:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 10:22:27 -0000 Subject: [GHC] #12150: Compile time performance degradation on code that uses undefined/error with CallStacks In-Reply-To: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> References: <045.a0bd3502ce7a1f35f82939f7b0bb87d6@haskell.org> Message-ID: <060.c509d0bb538cee8c75f86f4ce375bbff@haskell.org> #12150: Compile time performance degradation on code that uses undefined/error with CallStacks -------------------------------------+------------------------------------- Reporter: thomie | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T12150 Blocked By: | Blocking: Related Tickets: #10844 | Differential Rev(s): Phab:D3753 Wiki Page: | -------------------------------------+------------------------------------- Changes (by saurabhnanda): * cc: saurabhnanda (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 10:23:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 10:23:55 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.b153185ac6937a19046f0112e51dcd93@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): * cc: saurabhnanda (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 10:28:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 10:28:17 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.e2e77cc2f982de274d4f2d52926fdbbb@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): > Well, the overhead may (nearly) disappear entirely if the function with the constraint is inlined. If not then you will pay the cost of an additional pointer argument and possibly a constructor allocation. What would be a sensible way to benchmark this runtime cost? I'm in the process of evaluating the impact of enabling `HasCallstack` all throughout my code and am putting together a benchmark. The perf impact of `HasCallstack` would be significantly lower than compiling with profiling enabled, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 10:28:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 10:28:48 -0000 Subject: [GHC] #13285: Bug in GHC.Stack.callStack when used with sections In-Reply-To: <050.81951777fb2bcb194935732bc18dc469@haskell.org> References: <050.81951777fb2bcb194935732bc18dc469@haskell.org> Message-ID: <065.44938d7f274e4f624bdad31f367c640e@haskell.org> #13285: Bug in GHC.Stack.callStack when used with sections -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | deSigar/should_run/T13285 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by saurabhnanda): * cc: saurabhnanda (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 10:31:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 10:31:11 -0000 Subject: [GHC] #13772: Cannot put HasCallStack on instances In-Reply-To: <047.d360e3ed5517211c4a279da62bac67fe@haskell.org> References: <047.d360e3ed5517211c4a279da62bac67fe@haskell.org> Message-ID: <062.a2b331d821cece411330d4c6bbb0539e@haskell.org> #13772: Cannot put HasCallStack on instances -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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 saurabhnanda): * cc: saurabhnanda (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 10:45:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 10:45:36 -0000 Subject: [GHC] #14409: Split GHC(-API) into multiple packages Message-ID: <046.310c45ec4dd3ba940f204de806999eed@haskell.org> #14409: Split GHC(-API) into multiple packages -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: task | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- Current GHC-API is pretty monolithic and a lot of data is hidden in monads. I'd prefer to have cleanly separated packages for parser, module system, type-checker, optimizer, code generator, linker. E.g. Haddock would certainly only use the first two, maybe three, steps. Advanced editing features in an IDE would use only the first three steps. A compiler for a Haskell dialect might use only optimizer and code generator. The packages should have clean interfaces. E.g. it should be possible to enter a Text or String into the parser and get a ByteString containing code or a pointer to executable code in memory from the code generator, with no need to write temporary files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 12:46:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 12:46:21 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.c21e0febf98b769ee28493be79c348fb@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 gridaphobe): > What would be a sensible way to benchmark this runtime cost? I did a couple [https://github.com/gridaphobe/located- base/blob/master/bench/Bench.hs microbenchmarks] a while ago. They only test the cost of constructing and passing the `CallStack` around, so it's not necessarily an accurate reflection of the cost of enabling `HasCallStack` in real-world code. Your benchmarks would be a valuable addition! > The perf impact of HasCallstack would be significantly lower than compiling with profiling enabled, right? I suspect so, since the profiling machinery can also interfere with optimizations whereas the `CallStack`s do not, but I've never checked the difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 14:20:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 14:20:11 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.3c2b3a2910bf49ef673d0e5615dd4c07@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): * Attachment "numTerms.png" added. Generated Core, number of terms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 14:21:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 14:21:06 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.0a44f79f21b79715f31bc85c25a96b8f@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): * Attachment "simplSize.png" added. Generated Core, total size (in LOC) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 14:22:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 14:22:06 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.3b5ce9f2c6b3312c7ea926b9681af7a3@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): * Attachment "stgSize.png" added. Generated STG, total size (in LOC) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 14:22:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 14:22:33 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.688260a58c91ea60952dcd32fc64818a@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): * Attachment "cmmSize.png" added. Generated C--, total size (in LOC) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 14:23:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 14:23:02 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.2388ac40e09736035b9962c1596f32a5@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): * Attachment "totalTime.png" added. Total execution time (CPU, seconds) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 14:33:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 14:33:02 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.f4f06a53d71d59633a7eabb6068a5ec6@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): Some better data extraction code for profiles generated earlier yields the above graphs. All of these were generated using the optimization as implemented in D4145 (using a UniqSet instead of a list). Observations: - The number of terms in generated Core scales in a perfectly linear fashion for all examples. - The size of the generated Core in lines-of-code, however, scales non- linearly, which tells us that the size of individual terms grows with input size. This behavior seems to be identical between all 4 examples though, so it does not explain the extreme performance differences. - Somewhere between Core and STG, the `show` and `read` examples misbehave more badly than the other two - Between STG and C--, things get utterly dramatic, `show` and `read` explode, while `getline-appl` and `nothing` are reduced back to near- linear behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 14:39:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 14:39:50 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.04a1b3463195638fbfe181da648a7478@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): > I did a couple ​microbenchmarks a while ago. Thanks for sharing the benchmarks. They seem to be reporting a 50-250% slowdown with HasCallstack. My hunch is that the slowdown is linear wrt the depth of the call-stack. Will need to do some benchmarking to be sure of this. Do you know what the underlying data-structure for storing the call-stack is? IIUC, callstacks have been implemented as an extra implicit argument, and the slowdown shouldn't be more than adding a regular argument (say, a global configuration record) to a regular function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 14:51:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 14:51:40 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.33e7c80fad2fc87ca911ecb7f9e73ff2@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 gridaphobe): The underlying data structure is a slight twist on a linked list. https://hackage.haskell.org/package/base-4.10.0.0/docs/src/GHC.Stack.Types.html#CallStack The `FreezeCallStack` constructor is an experimental addition to let library authors avoid exposing implementation details in `CallStack`s. You're right that the cost of adding a `CallStack` should be roughly equivalent to passing another argument around, plus the cost of allocating each source location in the stack. It would make sense for the cost to be linear in the depth of the stack, each addition needs to allocate a new `PushCallStack` constructor, but maybe the constant factors can be improved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 15:15:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 15:15:56 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.3c28c28c41b2a774e807d88bcb1e9a77@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): > You're right that the cost of adding a CallStack should be roughly equivalent to passing another argument around, plus the cost of allocating each source location in the stack. I'm amazed that this operation ends up causing a 2-3x slowdown, although, to be fair, the scale is in the range of ~100ns. I think a more realistic benchmark would be wrt actual IO or parsing, where the time-scale of underlying operations will outweigh the minor performance hit added by HasCallstack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 17:20:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 17:20:58 -0000 Subject: [GHC] #14410: Windows 10 freeze caused by infinite recursion in WinGHCi Message-ID: <046.1ddf55fb3dfb9f3b6345d9be1b918869@haskell.org> #14410: Windows 10 freeze caused by infinite recursion in WinGHCi -------------------------------------+------------------------------------- Reporter: WinKlim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: freeze | Operating System: Windows infinite recursion | Architecture: x86_64 | Type of failure: Other (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Got Windows freeze after I typed this in WinGHCi : {{{ Prelude> fib2 a b n = fib2 b (a+b) (n-1) Prelude> fib2 3 3 1 }}} With option +RTS -M1000m I didn't get the Windows freeze but the termination of the calculation didn't work in WinGHCi . Operating system : Windows 10 64 Bit . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 23:51:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 23:51:57 -0000 Subject: [GHC] #9249: Link to "latest" user's guide In-Reply-To: <047.de05e08954a03649b76e01617284c75d@haskell.org> References: <047.de05e08954a03649b76e01617284c75d@haskell.org> Message-ID: <062.c9b6a322120c251120c4ffcf47528234@haskell.org> #9249: Link to "latest" user's guide -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: Documentation | 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: | -------------------------------------+------------------------------------- Comment (by ntc2): This feature would be more useful if a link to the corresponding page in the latest documentation was included when possible, not just a link to the top level of the latest manual. I've gotten used to adding `inurl:latest` to my GHC related Google queries in order to get up-to-date result. As a simpler improvement, the header with the links could just suggest the user repeat their search with `inurl:latest` included. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 1 23:58:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Nov 2017 23:58:06 -0000 Subject: [GHC] #14410: Windows 10 freeze caused by infinite recursion in WinGHCi In-Reply-To: <046.1ddf55fb3dfb9f3b6345d9be1b918869@haskell.org> References: <046.1ddf55fb3dfb9f3b6345d9be1b918869@haskell.org> Message-ID: <061.73fb2d043e2541d9559d99ac313195fe@haskell.org> #14410: Windows 10 freeze caused by infinite recursion in WinGHCi -------------------------------------+------------------------------------- Reporter: WinKlim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: freeze | infinite recursion Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Strange. Not the behaviour I'm getting (I'm at 8.0 -- but I don't think this will have changed at 8.2). > the termination of the calculation didn't work What do you expect to happen for "termination"? What do you expect for the types of the arguments (each of the three), and for the result? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 08:57:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 08:57:06 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.28fe1da08ee687c92eb1bbf2dbcf5651@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 simonpj): > I'm amazed that this operation ends up causing a 2-3x slowdown I'm amazed too. I'd suggest investigating a bit deeper. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 10:18:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 10:18:48 -0000 Subject: [GHC] #14347: Top-level RecordWildCards no longer working. In-Reply-To: <047.9d7d4bc51f0d30fd962b21bdfacfc205@haskell.org> References: <047.9d7d4bc51f0d30fd962b21bdfacfc205@haskell.org> Message-ID: <062.6e472a226b531838bd12f5bde8cb3197@haskell.org> #14347: Top-level RecordWildCards no longer working. -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Fuuzetsu): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 10:33:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 10:33:12 -0000 Subject: [GHC] #8171: Extending ExtendedDefaultRules In-Reply-To: <045.d77bd9544286ea508e1fa1aea2399f0c@haskell.org> References: <045.d77bd9544286ea508e1fa1aea2399f0c@haskell.org> Message-ID: <060.9a57f45f0ad75474a364896d54bbf055@haskell.org> #8171: Extending ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: | ExtendedDefaultRules Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2641 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mentheta): * cc: mentheta (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 11:04:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 11:04:18 -0000 Subject: [GHC] #14411: `make fasttest` exits successfully even in presence of failures Message-ID: <047.a89ff3751f3bb0ca676c5fa509a7a698@haskell.org> #14411: `make fasttest` exits successfully even in presence of failures -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 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: -------------------------------------+------------------------------------- {{{ ./boot ./configure make make fasttest … }}} I have seen on OSX that even when tests failed, `make fasttest` exited successfully. I have informed Ben at the time and this ticket is just to track progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 11:06:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 11:06:40 -0000 Subject: [GHC] #14412: Can't run tests with sdist -> bindist -> test Message-ID: <047.3a46ca6eb3118cf3818271a539f94cc4@haskell.org> #14412: Can't run tests with sdist -> bindist -> test -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 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 you want to make source dist, compile it into bindist then run tests with the bindist, it fails. {{{ mk/get-win32-tarballs.sh download all ./boot ./configure "$@" make sdist mkdir -p sdist-build-dir pushd sdist-build-dir shopt -s extglob tar xvfJ ../sdistprep/ghc-*+([[:digit:]])-src.tar.xz sdist-build-dir cd ghc-* ./boot ./configure "$@" make -j$THREADS make binary-dist popd mkdir -p bdist-test-dir pushd bdist-test-dir tar xvfJ ../sdist-build-dir/ghc-*/ghc-*.tar.xz tar xvfJ ../sdistprep/ghc*testsuite.tar.xz cd ghc-* ./configure make test }}} I do not have the failure error on hand but it had to do with Haddock trying to read its version from .cabal file which was not included in the bindist/sdist. I have communicated this problem to Ben at the time and this ticket is just to track progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 11:37:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 11:37:39 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.448eb8ec31a6ba1a7adadf0b73678c8b@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): It seems that for the misbehaving examples, the offensive cost centre is Stg2Stg. As code size increases, CPU time for this cost centre grows disproportionally in the `read` and `show` examples, while it remains below 40% for the well-behaved ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 12:53:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 12:53:52 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.2797473b18f6dd719c1e5b09fe98f0b0@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 simonpj): > the offensive cost centre is Stg2Stg Very interesting! Keep digging :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 13:42:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 13:42:44 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.a129dd79f725eb1d0e037052afb4dc7f@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | 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 RyanGlScott): Actually, it's not just limited to datatypes: the same effect can be observed in this program: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where type family F a data Foo (z :: F a) bar :: forall a (z :: F a). Foo z -> Int bar _ = 42 }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:10:33: error: • Expected kind ‘F a0’, but ‘z’ has kind ‘F a’ • In the first argument of ‘Foo’, namely ‘z’ In the type signature: bar :: forall a (z :: F a). Foo z -> Int | 10 | bar :: forall a (z :: F a). Foo z -> Int | ^ }}} Here, I would expect `AllowAmbiguousTypes` to squash the error message about the ambiguous variable `a0` in `F a0`, but that doesn't happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 14:06:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 14:06:34 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.dba5dfbad19d435f3df55e352b28e55f@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 bgamari): Well, keep in mind that the call stacks will slightly increase the size of the core and therefore things that GHC previously decided to inline may no longer be inlined. However, the size of the affect is still surprising. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 14:56:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 14:56:48 -0000 Subject: [GHC] #5889: -fno-prof-count-entries leads to linking errors In-Reply-To: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> References: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> Message-ID: <058.7bff1ef57de34f62a1d6f5d5e9bb95ec@haskell.org> #5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed I can reproduce this exact behavior. Investigating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 14:57:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 14:57:43 -0000 Subject: [GHC] #5889: -fno-prof-count-entries leads to linking errors In-Reply-To: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> References: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> Message-ID: <058.7a9e52858a32def33566044f1f64b25b@haskell.org> #5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 16:20:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 16:20:32 -0000 Subject: [GHC] #14413: Profiling breaks determinism Message-ID: <046.99e30ca5e93737bb465713a1e875ab35@haskell.org> #14413: Profiling breaks determinism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: determinism | 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 looking at #5889 I noticed that `CostCentre` currently includes a `Unique` (although it's represented as an `Int` for reasons that aren't relevant here; I change this in Phab:D4148). This unique identifies the cost centre and appears to be derived from the unique of a binder. This presumably breaks determinism. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 17:09:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 17:09:43 -0000 Subject: [GHC] #14174: GHC panic with TypeInType and type family In-Reply-To: <045.87c0508a41a6d0d9834ba40ef8506297@haskell.org> References: <045.87c0508a41a6d0d9834ba40ef8506297@haskell.org> Message-ID: <060.3962f38414919b5dea35456822471841@haskell.org> #14174: GHC panic with TypeInType and type family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This might be another occurrence of this bug: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind data TyFun :: * -> * -> * type a ~> b = TyFun a b -> * infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 type a @@ b = Apply a b infixl 9 @@ data FunArrow = (:->) | (:~>) class FunType (arr :: FunArrow) where type Fun (k1 :: Type) arr (k2 :: Type) :: Type class FunType arr => AppType (arr :: FunArrow) where type App k1 arr k2 (f :: Fun k1 arr k2) (x :: k1) :: k2 type FunApp arr = (FunType arr, AppType arr) instance FunType (:->) where type Fun k1 (:->) k2 = k1 -> k2 instance AppType (:->) where type App k1 (:->) k2 (f :: k1 -> k2) x = f x instance FunType (:~>) where type Fun k1 (:~>) k2 = k1 ~> k2 instance AppType (:~>) where type App k1 (:~>) k2 (f :: k1 ~> k2) x = f @@ x infixr 0 -?> type (-?>) (k1 :: Type) (k2 :: Type) (arr :: FunArrow) = Fun k1 arr k2 type family ElimBool (p :: Bool -> Type) (z :: Bool) (pFalse :: p False) (pTrue :: p True) :: p z where -- Commenting out the line below makes the panic go away ElimBool p z pFalse pTrue = ElimBoolPoly (:->) p z pFalse pTrue type family ElimBoolTyFun (p :: Bool ~> Type) (z :: Bool) (pFalse :: p @@ False) (pTrue :: p @@ True) :: p @@ z where ElimBoolTyFun p z pFalse pTrue = ElimBoolPoly (:~>) p z pFalse pTrue type family ElimBoolPoly (arr :: FunArrow) (p :: (Bool -?> Type) arr) (z :: Bool) (pFalse :: App Bool arr Type p False) (pTrue :: App Bool arr Type p True) :: App Bool arr Type p z where ElimBoolPoly _ _ False pFalse _ = pFalse ElimBoolPoly _ _ True _ pTrue = pTrue }}} {{{ $ /opt/ghc/8.2.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): piResultTy k0_a1Zd[tau:1] z_aS3[sk:1] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:948:35 in ghc:Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 17:30:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 17:30:45 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.faffc6caba2e72cefdb4dbdeb07ef78b@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10577, #13117 | Differential Rev(s): Phab:D4047 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1317ba625d40fbd51cb0538b3fde28f412f30c01/ghc" 1317ba62/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1317ba625d40fbd51cb0538b3fde28f412f30c01" Implement the EmptyDataDeriving proposal This implements the `EmptyDataDeriving` proposal put forth in https://github.com/ghc-proposals/ghc- proposals/blob/dbf51608/proposals/0006-deriving-empty.rst. This has two major changes: * The introduction of an `EmptyDataDeriving` extension, which permits directly deriving `Eq`, `Ord`, `Read`, and `Show` instances for empty data types. * An overhaul in the code that is emitted in derived instances for empty data types. To see an overview of the changes brought forth, refer to the changes to the 8.4.1 release notes. Test Plan: ./validate Reviewers: bgamari, dfeuer, austin, hvr, goldfire Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #7401, #10577, #13117 Differential Revision: https://phabricator.haskell.org/D4047 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 17:30:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 17:30:45 -0000 Subject: [GHC] #13117: Derived functor instance for void types handles errors badly In-Reply-To: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> References: <045.5f4239c38cee840f76e0399df57c685e@haskell.org> Message-ID: <060.ef3c7cef5b377d56dd4b6dd744885b73@haskell.org> #13117: Derived functor instance for void types handles errors badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7401, #10577 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1317ba625d40fbd51cb0538b3fde28f412f30c01/ghc" 1317ba62/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1317ba625d40fbd51cb0538b3fde28f412f30c01" Implement the EmptyDataDeriving proposal This implements the `EmptyDataDeriving` proposal put forth in https://github.com/ghc-proposals/ghc- proposals/blob/dbf51608/proposals/0006-deriving-empty.rst. This has two major changes: * The introduction of an `EmptyDataDeriving` extension, which permits directly deriving `Eq`, `Ord`, `Read`, and `Show` instances for empty data types. * An overhaul in the code that is emitted in derived instances for empty data types. To see an overview of the changes brought forth, refer to the changes to the 8.4.1 release notes. Test Plan: ./validate Reviewers: bgamari, dfeuer, austin, hvr, goldfire Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #7401, #10577, #13117 Differential Revision: https://phabricator.haskell.org/D4047 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 17:30:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 17:30:45 -0000 Subject: [GHC] #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit In-Reply-To: <048.e821713d1c06a4d751fa396103744323@haskell.org> References: <048.e821713d1c06a4d751fa396103744323@haskell.org> Message-ID: <063.505e14b6a0682b20df233b5517f0684b@haskell.org> #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit -------------------------------------+------------------------------------- Reporter: michelmno | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: 12469 | Blocking: Related Tickets: #14244 | Differential Rev(s): Phab:D3984 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1130c67bbb6dc06f513e5c8705a488a591fabadb/ghc" 1130c67b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1130c67bbb6dc06f513e5c8705a488a591fabadb" PPC NCG: Impl branch prediction, atomic ops. Implement AtomicRMW ops, atomic read, atomic write in PowerPC native code generator. Also implement branch prediction because we need it in atomic ops anyway. This patch improves the issue in #12537 a bit but does not fix it entirely. The fallback operations for atomicread and atomicwrite in libraries/ghc-prim/cbits/atomic.c are incorrect. This patch avoids those functions by implementing the operations directly in the native code generator. This is also what the x86/amd64 NCG and the LLVM backend do. Test Plan: validate on AIX and PowerPC (32-bit) Linux Reviewers: erikd, hvr, austin, bgamari, simonmar Reviewed By: hvr, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #12537 Differential Revision: https://phabricator.haskell.org/D3984 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 17:30:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 17:30:45 -0000 Subject: [GHC] #14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO In-Reply-To: <046.213052b44c9d3401325e49943e41332d@haskell.org> References: <046.213052b44c9d3401325e49943e41332d@haskell.org> Message-ID: <061.ada7de1823b3c791372e037f936f23bc@haskell.org> #14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4113 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b938576d151731b85314987fc550c17cfe824178/ghc" b938576/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b938576d151731b85314987fc550c17cfe824178" Add custom exception for fixIO Traditionally, `fixIO f` throws `BlockedIndefinitelyOnMVar` if `f` is strict. This is not particularly friendly, since the `MVar` in question is just part of the way `fixIO` happens to be implemented. Instead, throw a new `FixIOException` with a better explanation of the problem. Reviewers: austin, hvr, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14356 Differential Revision: https://phabricator.haskell.org/D4113 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 17:30:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 17:30:45 -0000 Subject: [GHC] #10577: Use empty cases where appropriate when deriving instances for empty types In-Reply-To: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> References: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> Message-ID: <062.b5acce0176d6f90bea5695e00176dce2@haskell.org> #10577: Use empty cases where appropriate when deriving instances for empty types -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13117, #7401 | Differential Rev(s): Phab:D4047 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1317ba625d40fbd51cb0538b3fde28f412f30c01/ghc" 1317ba62/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1317ba625d40fbd51cb0538b3fde28f412f30c01" Implement the EmptyDataDeriving proposal This implements the `EmptyDataDeriving` proposal put forth in https://github.com/ghc-proposals/ghc- proposals/blob/dbf51608/proposals/0006-deriving-empty.rst. This has two major changes: * The introduction of an `EmptyDataDeriving` extension, which permits directly deriving `Eq`, `Ord`, `Read`, and `Show` instances for empty data types. * An overhaul in the code that is emitted in derived instances for empty data types. To see an overview of the changes brought forth, refer to the changes to the 8.4.1 release notes. Test Plan: ./validate Reviewers: bgamari, dfeuer, austin, hvr, goldfire Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #7401, #10577, #13117 Differential Revision: https://phabricator.haskell.org/D4047 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 17:31:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 17:31:46 -0000 Subject: [GHC] #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit In-Reply-To: <048.e821713d1c06a4d751fa396103744323@haskell.org> References: <048.e821713d1c06a4d751fa396103744323@haskell.org> Message-ID: <063.677ca9aa81d31e1ae9e05c0c848ea602@haskell.org> #12537: Parallel cabal builds Segmentation Fault on PowerPC 64-bit -------------------------------------+------------------------------------- Reporter: michelmno | Owner: trommler Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: 12469 | Blocking: Related Tickets: #14244 | Differential Rev(s): Phab:D3984 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 Comment: Hopefully that will fix it. hvr will test when testing 8.4.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 17:31:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 17:31:57 -0000 Subject: [GHC] #14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO In-Reply-To: <046.213052b44c9d3401325e49943e41332d@haskell.org> References: <046.213052b44c9d3401325e49943e41332d@haskell.org> Message-ID: <061.ed151442876f765b7fafc931fec0f2c5@haskell.org> #14356: "Main: thread blocked indefinitely in an MVar operation" in fixIO -------------------------------------+------------------------------------- Reporter: nickkuk | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4113 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 18:00:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 18:00:00 -0000 Subject: [GHC] #14410: Windows 10 freeze caused by infinite recursion in WinGHCi In-Reply-To: <046.1ddf55fb3dfb9f3b6345d9be1b918869@haskell.org> References: <046.1ddf55fb3dfb9f3b6345d9be1b918869@haskell.org> Message-ID: <061.4e528fd69a8ba5ff529d6c2f5221dbd1@haskell.org> #14410: Windows 10 freeze caused by infinite recursion in WinGHCi -------------------------------------+------------------------------------- Reporter: WinKlim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: freeze | infinite recursion Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by WinKlim): I expect that the "Stop program execution"-button terminates the calculation. I dont't expect any result since this is an infinite recursion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 19:00:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 19:00:20 -0000 Subject: [GHC] #5889: -fno-prof-count-entries leads to linking errors In-Reply-To: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> References: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> Message-ID: <058.6b5941f591f27d3cb892a97c565e6ff8@haskell.org> #5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, I know what is going on here: Look at the simplified Core of `Type.newTyConInstRhs`, {{{ newTyConInstRhs :: TyCon -> [Type] -> Type [GblId, Arity=2, Str=, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=2,unsat_ok=True,boring_ok=False) Tmpl= \ (tycon_a9Sq [Occ=OnceL] :: TyCon) (tys_a9Sr [Occ=OnceL] :: [Type]) -> scc let { ds_sofN :: ([TyVar], Type) [LclId] ds_sofN = scc newTyConEtadRhs tycon_a9Sq } in applyTysX (scc case ds_sofN of { (tvs_ab8F [Occ=Once], _ [Occ=Dead]) -> tvs_ab8F }) (scc case ds_sofN of { (_ [Occ=Dead], rhs_ab8H [Occ=Once]) -> rhs_ab8H }) tys_a9Sr}] newTyConInstRhs = \ (tycon_a9Sq :: TyCon) (tys_a9Sr :: [Type]) -> scc case scc newTyConEtadRhs tycon_a9Sq of { (ww1_suMl, ww2_suMm) -> applyTysX ww1_suMl ww2_suMm tys_a9Sr } }}} Note how the unfolding contains references to two SCCs, `newTyConInstRhs.tvs` and `newTyConInstRhs.rhs`, which do not appear in the RHS. Indeed these were both present in the original desugared Core, so it seems like the simplifier eliminated them. I'm not yet sure why it does this, nor do I know why this is only triggered with `-fno-prof-count- entries`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 19:16:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 19:16:01 -0000 Subject: [GHC] #5889: -fno-prof-count-entries leads to linking errors In-Reply-To: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> References: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> Message-ID: <058.eb4b1fa78bd9f4e6390d3ac76db6fa0d@haskell.org> #5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, the rest is pretty clear I think: Note that in the RHS of the simplified `newTyConInstRhs` the ticks should wrap the two arguments `ww1_suMl` and `ww2_suMm` but don't. `CoreUtils.mkTick` has the following case for ticks wrapping `Var`s, {{{#!hs mkTick' top rest expr = case expr of ... Var x | notFunction && tickishPlace t == PlaceCostCentre -> orig_expr | notFunction && canSplit -> top $ Tick (mkNoScope t) $ rest expr where -- SCCs can be eliminated on variables provided the variable -- is not a function. In these cases the SCC makes no difference: -- the cost of evaluating the variable will be attributed to its -- definition site. When the variable refers to a function, however, -- an SCC annotation on the variable affects the cost-centre stack -- when the function is called, so we must retain those. notFunction = not (isFunTy (idType x)) }}} Moreover, `CoreSyn.tickishPlace` is defined thusly, {{{#!hs tickishPlace :: Tickish id -> TickishPlacement tickishPlace n at ProfNote{} | profNoteCount n = PlaceRuntime | otherwise = PlaceCostCentre ... }}} This is how the counting and non-counting cases are treated differently. So in short, in the non-counting case we try to wrap a `Var` expression in a tick. `mkTick` then notices that such a tick can be dropped and does so. However, the tick remains in the unfolding. Consequently, when we inline `newTyConInstRhs` in another module we end up with a reference to a cost center whose corresponding symbol doesn't exist in the module that is supposed to define it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 19:18:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 19:18:15 -0000 Subject: [GHC] #5889: -fno-prof-count-entries leads to linking errors In-Reply-To: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> References: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> Message-ID: <058.d830dafd3c75c24eba6cd8d349f2bd3b@haskell.org> #5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Jaffacake (added) Comment: Off the top of my head I see a few general directions for fixing this: 1. Be less aggressive about dropping "useless" ticks 2. Ensure that during codegen we look for SCCs in unfoldings as well as the RHS itself -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 19:36:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 19:36:26 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled Message-ID: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 was looking at benchmarks game (attached as fasta.ghc-2.hs). I have found that with the flags give there, this program on GHC 8.2.1 runs in about a second with `-prof -fprof-auto` and 2.5 seconds without! To run without profiling: {{{ ghc --make -Wall -fforce-recomp -fllvm -O2 -XBangPatterns -threaded -rtsopts -XOverloadedStrings fasta.ghc-2.hs -o fasta.ghc-2.ghc_run && ./fasta.ghc-2.ghc_run +RTS -N4 -s -RTS 250000 > /dev/null }}} Same program with profiling {{{ ghc --make -fforce-recomp -fllvm -prof -fprof-auto -O2 -XBangPatterns -threaded -rtsopts -XOverloadedStrings fasta.ghc-2.hs -o fasta.ghc-2.ghc_run && ./fasta.ghc-2.ghc_run +RTS -N4 -p -s -RTS 250000 > /dev/null }}} I also attach Core outputs for both profiled and unprofiled version. To me this seems very strange: profiled version is somehow faster. Perhaps what's worse is that this means that there's some optimisation GHC is performing when profiling is not on that makes the program a lot slower than it could be! This program is not minimised. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 19:36:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 19:36:41 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled In-Reply-To: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> References: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> Message-ID: <062.de72425a5b3bf8431fb1246275a38366@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Fuuzetsu): * Attachment "fasta.ghc-2.hs" added. Program itself -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 19:37:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 19:37:04 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled In-Reply-To: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> References: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> Message-ID: <062.d94470b1c5c6a0394297056adcc23ea9@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Fuuzetsu): * Attachment "fasta.ghc-2.dump-simpl-prof" added. Core of profile program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 19:37:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 19:37:20 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled In-Reply-To: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> References: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> Message-ID: <062.c441cee917f814b955474fb32c4ba685@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Fuuzetsu): * Attachment "fasta.ghc-2.dump-simpl-no-prof" added. Core of unprofiled program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 19:48:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 19:48:53 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled In-Reply-To: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> References: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> Message-ID: <062.7efa145380e7470c162fe1d1f9d426a1@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): Hmm, this appears to be a different version of `fasta` than what we have in `nofib`. Perhaps it would make for a good addition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 19:50:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 19:50:50 -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.5330411349ea078e07113366e956c0c6@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 ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 19:54:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 19:54:55 -0000 Subject: [GHC] #5889: -fno-prof-count-entries leads to linking errors In-Reply-To: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> References: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> Message-ID: <058.41393b3ac8d248b2d02aa97bbe3391c5@haskell.org> #5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): What a great diagnosis. I will construct a test case for this next week if you have not already done so. Note [inline sccs] in Coverage.hs seems relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 20:16:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 20:16:23 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled In-Reply-To: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> References: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> Message-ID: <062.682d05ef575d5dd7bf37bd8d9f1507ff@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): I must be missing something; I can't reproduce on Linux with GHC 8.2.1 and LLVM 3.9.1. ||= Flags = ||= NCG =||= NCG =||= LLVM =||= LLVM =|| || ||= MUT =||= GC =||= MUT =||= GC =|| || `-O0` || 24.8 || 5.42 || 24.22 || 5.42 || || `-O1` || 6.55 || 1.24 || 4.38 || 0.73 || || `-O2` || 5.37 || 0.91 || 4.28 || 0.83 || || `-O1 -prof` || 8.68 || 1.68 || 7.78 || 1.36 || || `-O2 -prof` || 8.28 || 1.47 || 7.13 || 1.58 || || `-O1 -prof -fprof-auto` || 17.63 || 1.72 || 17.01 || 1.95 || || `-O2 -prof -fprof-auto` || 15.26 || 1.71 || 14.36 || 1.64 || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 20:18:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 20:18:20 -0000 Subject: [GHC] #14415: Win32 SEH unwinding should print segfaults to stderr, not stdout Message-ID: <051.c9a792f5c8906425b56d08077a9b1ab2@haskell.org> #14415: Win32 SEH unwinding should print segfaults to stderr, not stdout -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1 System | Keywords: | Operating System: Windows Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Looking at ghc/rts/win32/veh_excn.c we can see that on segfaults, e.g. null pointer access, GHC calls: {{{ fprintf(stdout, "Access violation in generated code" }}} Given these are segfaults, it seems that stderr would be a more appropriate stream to use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 20:20:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 20:20:06 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled In-Reply-To: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> References: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> Message-ID: <062.84ce72c5e652b2910edf565e284e8c0e@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): Using the command lines given in the ticket description: || ||= MUT =||= GC =|| ||= Without profiling =|| 0.152 || 0.116 || ||= With profiling =|| 0.843 || 0.293 || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 21:04:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 21:04:05 -0000 Subject: [GHC] #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers In-Reply-To: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> References: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> Message-ID: <062.2727ea1ff9674692b40b5d30edf87ae0@haskell.org> #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Prelude | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #12537 | Differential Rev(s): Phab:D4009 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bd765f4b1332b3d2a7908de3f9ff1d50da0e0b1d/ghc" bd765f4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bd765f4b1332b3d2a7908de3f9ff1d50da0e0b1d" Fix atomicread/write operations In `libraries/ghc-prim/cbits/atomic.c` no barriers were issued for atomic read and write operations. Starting with gcc 4.7 compiler intrinsics are offered. The atomic intrinisics are also available in clang. Use these to implement `hs_atomicread*` and `hs_atomicwrite`. Test Plan: validate on OSX and Windows Reviewers: austin, bgamari, simonmar, hvr, erikd, dfeuer Reviewed By: bgamari Subscribers: dfeuer, rwbarton, thomie GHC Trac Issues: #14244 Differential Revision: https://phabricator.haskell.org/D4009 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 21:05:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 21:05:26 -0000 Subject: [GHC] #14412: Can't run tests with sdist -> bindist -> test In-Reply-To: <047.3a46ca6eb3118cf3818271a539f94cc4@haskell.org> References: <047.3a46ca6eb3118cf3818271a539f94cc4@haskell.org> Message-ID: <062.a5ef8e297caa11bf221a81a57a963ff8@haskell.org> #14412: Can't run tests with sdist -> bindist -> test -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.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 bgamari): * milestone: => 8.4.1 Comment: Alright, lacking a better idea I have reverted d9b6015d1942aa176e85bb71f34200bab54e1c9c since it breaks more than it fixes. Unfortunately this means that we still can't test binary distributions, but I'll try to fix this in Hadrian. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 21:17:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 21:17:02 -0000 Subject: [GHC] #5889: -fno-prof-count-entries leads to linking errors In-Reply-To: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> References: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> Message-ID: <058.7807db0f131c499babeafdef9840d303@haskell.org> #5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks, a testcase would be great! Indeed I didn't notice `Note [inline sccs]`. It's surprising that this bug wasn't spotted earlier given that this could happen for any binding, not just those marked as INLINE (since GHC may decide on its own to expose an unfolding). I guess `-fno-prof-count-entries` doesn't see much use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 22:50:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 22:50:27 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled In-Reply-To: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> References: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> Message-ID: <062.d1a2967b6c2aa5589b8d14c0d5161c12@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Fuuzetsu): I don't know what you could be missing. I removed LLVM. I'm on i7 6770k, 64GB RAM, SSD. {{{ [shana at lenalee:/tmp]$ ghc --make -ddump-simpl -ddump-to-file -fforce- recomp -O2 -XBangPatterns -threaded -rtsopts -XOverloadedStrings fasta.ghc-2.hs -o fasta.ghc-2.ghc_run && ./fasta.ghc-2.ghc_run +RTS -N4 -s -RTS 250000 > /dev/null [1 of 1] Compiling Main ( fasta.ghc-2.hs, fasta.ghc-2.o ) Linking fasta.ghc-2.ghc_run ... 368,568,064 bytes allocated in the heap 15,735,800 bytes copied during GC 3,692,976 bytes maximum residency (7 sample(s)) 226,896 bytes maximum slop 9 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 137 colls, 137 par 1.660s 1.660s 0.0121s 0.0280s Gen 1 7 colls, 6 par 0.127s 0.127s 0.0182s 0.0274s Parallel GC work balance: 35.73% (serial 0%, perfect 100%) TASKS: 10 (1 bound, 9 peak workers (9 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.000s ( 0.000s elapsed) MUT time 0.206s ( 0.206s elapsed) GC time 1.787s ( 1.787s elapsed) EXIT time 0.000s ( 0.007s elapsed) Total time 1.993s ( 2.000s elapsed) Alloc rate 1,789,756,100 bytes per MUT second Productivity 10.3% of total user, 10.7% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 [shana at lenalee:/tmp]$ ghc --make -ddump-simpl -ddump-to-file -prof -fprof- auto -fforce-recomp -O2 -XBangPatterns -threaded -rtsopts -XOverloadedStrings fasta.ghc-2.hs -o fasta.ghc-2.ghc_run && ./fasta.ghc-2.ghc_run +RTS -N4 -s -p -RTS 250000 > /dev/null [1 of 1] Compiling Main ( fasta.ghc-2.hs, fasta.ghc-2.o ) Linking fasta.ghc-2.ghc_run ... 653,685,432 bytes allocated in the heap 42,865,544 bytes copied during GC 4,548,264 bytes maximum residency (9 sample(s)) 584,024 bytes maximum slop 10 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 256 colls, 256 par 0.371s 0.371s 0.0014s 0.0073s Gen 1 9 colls, 8 par 0.015s 0.015s 0.0017s 0.0063s Parallel GC work balance: 16.49% (serial 0%, perfect 100%) TASKS: 10 (1 bound, 9 peak workers (9 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.000s ( 0.000s elapsed) MUT time 0.487s ( 0.487s elapsed) GC time 0.386s ( 0.386s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.001s elapsed) Total time 0.874s ( 0.874s elapsed) Alloc rate 1,340,938,477 bytes per MUT second Productivity 55.8% of total user, 55.8% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 23:12:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 23:12:34 -0000 Subject: [GHC] #14415: Win32 SEH unwinding should print segfaults to stderr, not stdout In-Reply-To: <051.c9a792f5c8906425b56d08077a9b1ab2@haskell.org> References: <051.c9a792f5c8906425b56d08077a9b1ab2@haskell.org> Message-ID: <066.c8f7ae83cff2c68959e6691c7c47c9f8@haskell.org> #14415: Win32 SEH unwinding should print segfaults to stderr, not stdout -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4151 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Phyx- (added) * status: new => patch * differential: => Phab:D4151 * milestone: => 8.4.1 Comment: See Phab:D4151 for a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 23:17:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 23:17:22 -0000 Subject: [GHC] #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. In-Reply-To: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> References: <049.7ed7d5ba2f5e5e856922764e36628b22@haskell.org> Message-ID: <064.a4704f3ccb8b28cf0e7fa8e0fbe8e8c1@haskell.org> #7401: Can't derive instance for Eq when datatype has no constructor, while it is trivial do do so. -------------------------------------+------------------------------------- Reporter: jpbernardy | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.6.1 Resolution: fixed | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_run/T7401, | deriving/should_run/T7401_fail Blocked By: | Blocking: Related Tickets: #10577, #13117 | Differential Rev(s): Phab:D4047 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => deriving/should_run/T7401, deriving/should_run/T7401_fail * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 23:18:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 23:18:25 -0000 Subject: [GHC] #10577: Use empty cases where appropriate when deriving instances for empty types In-Reply-To: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> References: <047.96e36644fa4dc515076cb2f2c2be615c@haskell.org> Message-ID: <062.616da13eb17fd68008c440f1defb7145@haskell.org> #10577: Use empty cases where appropriate when deriving instances for empty types -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13117, #7401 | Differential Rev(s): Phab:D4047 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 23:20:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 23:20:42 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.196c7157c1c6b23b1ef7d37c71b7914c@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | 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 simonpj): In comment:6 we have {{{ Foo :: forall a. F a -> * }}} That's an ambiguous kind! Just like for a function {{{ foo :: forall k. F k -> Int }}} is ambiguous. So all uses of `Foo` will give rise to ambiguity. But alas we do not check for ambiguous kinds. Instead we see a "call" of `Foo` in the type signature {{{ bar :: forall a (z :: F a). Foo z -> Int }}} At the use of `Foo` we intantiate `k` to `kappa` and check that `F kappa` is equal o the kind of `z` namely `F a`. So for the type to be well- kinded we need `F kappa ~ F a`. But we have no way to prove that (unless `F` is injective). And that's the error. TL;DR: it's `Foo` that should be rejected as having an ambiguous kind. (I have not studied the oroginal Description; just assuming that comment:6 embodies the essence.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 2 23:23:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Nov 2017 23:23:43 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.707bdbdab03bf3877de14de0e2767647@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | 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 RyanGlScott): I'm well aware of the fact that this is an ambiguous definition. But the point that I'm making (that no one has addressed yet) is that `AllowAmbiguousTypes` should allow GHC to accept such a definition! Replying to [comment:7 simonpj]: > But alas we do not check for ambiguous kinds. If we don't do this currently, then we should! There are many programs that I can't write because of this restriction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 00:15:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 00:15:59 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.00c0c64e628564309e651d78ec28c1a8@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 Ben Gamari ): In [changeset:"43537568579a63cb6b8d70b4815d76c46bb9a692/ghc" 4353756/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="43537568579a63cb6b8d70b4815d76c46bb9a692" CmmSink: Use a IntSet instead of a list CmmProcs which have *lots* of local variables take a considerable amount of time in CmmSink. This was noticed by @tdammers in #7258 while compiling files with large records (~200-400 fields). Before: ``` Sun Oct 29 19:58 2017 Time and Allocation Profiling Report (Final) ghc-stage2 +RTS -p -RTS -B/Users/alexbiehl/git/ghc/inplace/lib /Users/alexbiehl/Downloads/W2.hs -fforce-recomp -O2 total time = 26.00 secs (25996 ticks @ 1000 us, 1 processor) total alloc = 14,921,627,912 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc sink CmmPipeline compiler/cmm/CmmPipeline.hs:(104,13)-(105,59) 55.7 15.9 SimplTopBinds SimplCore compiler/simplCore/SimplCore.hs:761:39-74 19.5 30.6 FloatOutwards SimplCore compiler/simplCore/SimplCore.hs:471:40-66 4.2 9.0 RegAlloc-linear AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(658,27)-(660,55) 4.0 11.1 pprNativeCode AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(529,37)-(530,65) 2.8 6.3 NewStranal SimplCore compiler/simplCore/SimplCore.hs:480:40-63 1.6 3.7 OccAnal SimplCore compiler/simplCore/SimplCore.hs:(739,22)-(740,67) 1.5 3.5 StgCmm HscMain compiler/main/HscMain.hs:(1426,13)-(1427,62) 1.2 2.4 regLiveness AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(591,17)-(593,52) 1.2 1.9 genMachCode AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(580,17)-(582,62) 0.9 1.8 NativeCodeGen CodeOutput compiler/main/CodeOutput.hs:171:18-78 0.9 2.1 CoreTidy HscMain compiler/main/HscMain.hs:1253:27-67 0.8 1.9 ``` After: ``` Sun Oct 29 19:18 2017 Time and Allocation Profiling Report (Final) ghc-stage2 +RTS -p -RTS -B/Users/alexbiehl/git/ghc/inplace/lib /Users/alexbiehl/Downloads/W2.hs -fforce-recomp -O2 total time = 13.31 secs (13307 ticks @ 1000 us, 1 processor) total alloc = 15,772,184,488 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc SimplTopBinds SimplCore compiler/simplCore/SimplCore.hs:761:39-74 38.3 29.0 sink CmmPipeline compiler/cmm/CmmPipeline.hs:(104,13)-(105,59) 13.2 20.3 RegAlloc-linear AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(658,27)-(660,55) 8.3 10.5 FloatOutwards SimplCore compiler/simplCore/SimplCore.hs:471:40-66 8.1 8.5 pprNativeCode AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(529,37)-(530,65) 5.4 5.9 NewStranal SimplCore compiler/simplCore/SimplCore.hs:480:40-63 3.1 3.5 OccAnal SimplCore compiler/simplCore/SimplCore.hs:(739,22)-(740,67) 2.9 3.3 StgCmm HscMain compiler/main/HscMain.hs:(1426,13)-(1427,62) 2.3 2.3 regLiveness AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(591,17)-(593,52) 2.1 1.8 NativeCodeGen CodeOutput compiler/main/CodeOutput.hs:171:18-78 1.7 2.0 genMachCode AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(580,17)-(582,62) 1.6 1.7 CoreTidy HscMain compiler/main/HscMain.hs:1253:27-67 1.4 1.8 foldNodesBwdOO Hoopl.Dataflow compiler/cmm/Hoopl/Dataflow.hs:(397,1)-(403,17) 1.1 0.8 ``` Reviewers: austin, bgamari, simonmar Reviewed By: bgamari Subscribers: duog, rwbarton, thomie, tdammers GHC Trac Issues: #7258 Differential Revision: https://phabricator.haskell.org/D4145 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 03:35:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 03:35:45 -0000 Subject: [GHC] #14416: CI with CircleCI Message-ID: <043.af09c8504e7db798b11a186aefc2b2d5@haskell.org> #14416: CI with CircleCI -------------------------------------+------------------------------------- Reporter: chak | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Build System | Version: Keywords: | 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: | ContinuousIntegration -------------------------------------+------------------------------------- Merging the PR with the new CircleCI per-commit builds for Linux/x86_64 and macOS/x86_64: https://github.com/ghc/ghc/pull/83 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 03:45:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 03:45:12 -0000 Subject: [GHC] #14410: Windows 10 freeze caused by infinite recursion in WinGHCi In-Reply-To: <046.1ddf55fb3dfb9f3b6345d9be1b918869@haskell.org> References: <046.1ddf55fb3dfb9f3b6345d9be1b918869@haskell.org> Message-ID: <061.9dcd2ecd2d0368b9256030f87637da1f@haskell.org> #14410: Windows 10 freeze caused by infinite recursion in WinGHCi ----------------------------+---------------------------------------- Reporter: WinKlim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #14150 | Differential Rev(s): Wiki Page: | ----------------------------+---------------------------------------- Changes (by Phyx-): * keywords: freeze infinite recursion => * cc: Phyx- (added) * architecture: x86_64 (amd64) => Unknown/Multiple * related: => #14150 Comment: What's `WinGHCI`? I assume some wrapper around `ghci.exe`? I think this is a duplicate of #14150. Try the recently released `8.2.2` RC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 04:30:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 04:30:53 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled In-Reply-To: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> References: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> Message-ID: <062.d9b499731a545e7035c0e07a9a64f798@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 duog): I couldn't reproduce this either. The times in comment:4 are strange, the elapsed times are the same as the normal times. The elasped times should be about 4x smaller. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 05:47:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 05:47:33 -0000 Subject: [GHC] #14410: Windows 10 freeze caused by infinite recursion in WinGHCi In-Reply-To: <046.1ddf55fb3dfb9f3b6345d9be1b918869@haskell.org> References: <046.1ddf55fb3dfb9f3b6345d9be1b918869@haskell.org> Message-ID: <061.c3f10b2b376b344a07ac4be3669172d2@haskell.org> #14410: Windows 10 freeze caused by infinite recursion in WinGHCi ----------------------------+---------------------------------------- Reporter: WinKlim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #14150 | Differential Rev(s): Wiki Page: | ----------------------------+---------------------------------------- Comment (by AntC): Replying to [comment:3 Phyx-]: > What's `WinGHCI`? [https://code.google.com/archive/p/winghci/wikis/WinGhciFeatures.wiki GHC's answer to WinHugs] > I assume some wrapper around `ghci.exe`? Yes, to a first approximation. > I think this is a duplicate of #14150. Thank you. Yes, looks likely. (That would explain why I'm not seeing it at 8.0.) > Try the recently released `8.2.2` RC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 08:25:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 08:25:36 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.b996ed35230e8c73e7da26bcc6ff24f0@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 alexbiehl): Replying to [comment:77 tdammers]: > It seems that for the misbehaving examples, the offensive cost centre is Stg2Stg. As code size increases, CPU time for this cost centre grows disproportionally in the `read` and `show` examples, while it remains below 40% for the well-behaved ones. Since you don't compile the examples with profiling on the only "heavy" transformation in Stg2Stg is StgCse. You can try `-fno-stg-cse` to see if it gets better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 08:38:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 08:38:17 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.8360dc233aaab2722a9966eb3f5a5de4@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | 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 simonpj): > But the point that I'm making (that no one has addressed yet) is that AllowAmbiguousTypes should allow GHC to accept such a definition! I don't agree. It's the definition of `Foo` that has an ambiguous kind. ThE type signature for `bar` is entirely innocent. To see this more clearly try {{{ bar :: forall a (z :: F a). Foo z -> Proxy z -> Int }}} Nothing ambiguous about that. But simply kind-checking the type signature fails because `Foo`'s kind is ambiguous. > If we don't do this currently, then we should! There are many programs that I can't write because of this restriction. ] What is "this"? Rejecting the definition of `Foo` (which would be the effect of checking `Foo`'s kind for ambiguity) would not typecheck more programs! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 08:43:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 08:43:12 -0000 Subject: [GHC] #14413: Profiling breaks determinism In-Reply-To: <046.99e30ca5e93737bb465713a1e875ab35@haskell.org> References: <046.99e30ca5e93737bb465713a1e875ab35@haskell.org> Message-ID: <061.9b19e34eb64ff3194652c6be7c2869c5@haskell.org> #14413: Profiling breaks determinism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: determinism 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 alexbiehl): We could use the associated `SrcLoc` to deterministically sort the CostCentres and for generating the C-Label. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 08:43:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 08:43:50 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.b3794e8ed8a35904e384f59929167c07@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 simonpj): Very curious. I see in comment:79 {{{ Before total time = 26.00 secs (25996 ticks @ 1000 us, 1 processor) total alloc = 14,921,627,912 bytes (excludes profiling overheads) After total time = 13.31 secs (13307 ticks @ 1000 us, 1 processor) total alloc = 15,772,184,488 bytes (excludes profiling overheads) }}} I don't think I have ever before seen a program that actually allocates more (15G instead of 14G) and yet runs in half the time. Usually allocation and runtime are more or less correlated. But apparently not in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 08:58:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 08:58:18 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.02282762c107f5a4c18b61bbf56da048@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): Stg2Stg turns out to b a dead end. The performance loss I observed there is entirely due to formatting and dumping about 1.3 GiB worth of STG when compiling with -ddump-stg; when compiling without -ddump-stg, `Stg2Stg` doesn't show up in the profile at all (0.0 on everything). Re-running the profiling script without dumps shows different culprits: `tryToInline`, and `simpl_bind`. E.g. 400-field `read`: {{{ Fri Nov 3 08:43 2017 Time and Allocation Profiling Report (Final) ghc-stage2 +RTS -p -h -RTS -B/home/tobias/well- typed/devel/ghc/inplace/lib -B/home/tobias/well- typed/devel/ghc/inplace/lib -O -fforce-recomp -c generated/t-400-read.hs total time = 59.05 secs (59049 ticks @ 1000 us, 1 processor) total alloc = 75,366,446,544 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc simpl_bind Simplify compiler/simplCore/Simplify.hs:141:83-101 29.4 22.0 tryToInline CmmSink compiler/cmm/CmmSink.hs:410:3-41 24.4 32.4 RegAlloc-linear AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(658,27)-(660,55) 10.6 14.1 FloatOutwards SimplCore compiler/simplCore/SimplCore.hs:471:40-66 8.8 6.9 pprNativeCode AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(529,37)-(530,65) 4.0 4.7 OccAnal SimplCore compiler/simplCore/SimplCore.hs:(739,22)-(740,67) 2.3 2.2 StgCmm HscMain compiler/main/HscMain.hs:(1426,13)-(1427,62) 2.1 1.8 regLiveness AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(591,17)-(593,52) 1.9 1.3 NativeCodeGen CodeOutput compiler/main/CodeOutput.hs:171:18-78 1.5 1.6 genMachCode AsmCodeGen compiler/nativeGen/AsmCodeGen.hs:(580,17)-(582,62) 1.4 1.3 CoreTidy HscMain compiler/main/HscMain.hs:1253:27-67 1.3 1.4 dmdAnal'-Case-single_prod_ctor DmdAnal compiler/stranal/DmdAnal.hs:(251,5)-(276,68) 1.3 1.5 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 09:07:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 09:07:02 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.f885e4807591e75f57ed85e7f59c49fa@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): * Attachment "t-read-scc-time-abs.png" added. Largest profiling cost centres (in absolute terms) for the `read` example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 09:07:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 09:07:36 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.77032a629432e0dada72f15e510526b7@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): * Attachment "t-getline-appl-scc-time-abs.png" added. Largest profiling cost centres (in absolute terms) for the `getline-appl` example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 09:08:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 09:08:41 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.3f23dc30ad5a0deee8c5b00a2253988b@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): * Attachment "t-show-scc-time-abs.png" added. Largest profiling cost centres (in absolute terms) for the `show` example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 09:12:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 09:12:50 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.ef0054237e263d40279a42ee18c976a6@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): Comparing the latest 3 graphs, we can see that `tryToInline` more badly than the other cost centres, at least in the misbehaving examples, while the other top cost centres seem to scale somewhat proportionally. `simpl_binds` is the largest one in most cases, but `tryToInline` is "more nonlinear" for the `show` and `read` examples, surpassing it between 150 and 200 fields in the `show` example, and (educated guess) around 500 fields in the `read` example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 11:15:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 11:15:28 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.6ede8b2d58097b56dc59959252c11c91@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 simonpj): `tryToInline` is in in `CmmSink` which we already know is working too hard. There may well be algorithmic improvements that could be done `CmmSink`. But, in addition, I would still like to understand why the STG-to-Cmm ratio climbs so sharply. If we have giant Cmm then any Cmm pass is going to take a long time. Fixing the non-linearity would be good, I agree; but generating less Cmm would also be big. Why is it so big? My guess: we are generating very deeply-nested closures that have a lot of free variables. E.g. {{{ let x = let a5 = blah q = ...K a1 a2 a3 a4 a5 ... in ... }}} Here the closure for `q` has 5 free variables (a1-a5); while that for `x` has four (a1-a4). So the code for `x` will slurp lots of variables out of x's closure only to store them again in q's. And if that is nested we'll get `O(n**2)` code size. But I'm speculating. Facts would be good. Let's measure STG size with and without counting the free vars of each closure (which are stored in the STG tree) and see. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 11:50:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 11:50:21 -0000 Subject: [GHC] #5889: -fno-prof-count-entries leads to linking errors In-Reply-To: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> References: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> Message-ID: <058.5152900f6476bfa11e468fc5a9700ad0@haskell.org> #5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > However, the tick remains in the unfolding * Why? If it is dropped in the RHS why isn't it dropped in the unfolding too? * Also, when that unfolding is later inlined at a call site, why isn't the tick eliminated then? Still, I suppose alternative (2) in comment:10 is also a plausible belt- and-braces approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 14:16:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 14:16:50 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.dbe8a522121a594f2f227e3d0a3b8af1@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | 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 RyanGlScott): Replying to [comment:9 simonpj]: > I don't agree. It's the definition of `Foo` that has an ambiguous kind. OK, sure. The point is—there's //some// definition in this program with an ambiguous kind, and `AllowAmbiguousTypes` is not convincing GHC to accept it. If the burden of ambiguity proof needs to be shifted to `Foo` instead, that's fine. > What is "this"? Rejecting the definition of `Foo` (which would be the effect of checking `Foo`'s kind for ambiguity) would not typecheck more programs! The point is that I //want// GHC to accept `Foo` (and `bar`). The mechanism by which I normally do so (`AllowAmbiguousTypes`) is failing me here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 14:28:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 14:28:58 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.78e9dc9a79c92db2c32e6373c6c6a9bc@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | 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 don't see how you want GHC to accept `bar`. Let's take this slowly. ``` type family F a ``` So far, so good. ``` data Foo (z :: F a) ``` As Simon points out, `Foo` has an ambiguous kind `forall (a :: Type). F a -> Type`. There's no way to infer the choice of `a` from a usage of `Foo`. GHC does not check for ambiguous kinds (it should, I agree), so this definition is accepted with or without `AllowAmbiguousTypes`. Regardless, you've specified `AllowAmbiguousTypes`, so accepting this conforms to your stated desires. ``` bar :: forall a (z :: F a). Foo z -> Int ``` Now we're in deep trouble. This type mentions `Foo z`. Accordingly, GHC must infer the invisible kind parameter to `Foo`. (You might say "Well, obviously it should be `a`!", but that would be assuming `F` is injective.) So GHC rejects this type signature, as it doesn't know what the invisible kind parameter to `Foo` should be. Note that this is ''not'' the normal ambiguity check that `AllowAmbiguousTypes` disables. This type has an ambiguous type variable; the type itself is not ambiguous. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 14:39:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 14:39:37 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.e4526e497053877b36fafde58429cc7c@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | 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 RyanGlScott): OK. So what you're saying is that: {{{#!hs bar :: forall a (z :: F a). Foo z -> Int }}} Should be rejected as an ambiguous //occurrence// site (which `AllowAmbiguousTypes` does not permit) rather than an ambiguous //definition// site (which `AllowAmbiguousType` //does// permit)? I could buy that, although I'm a bit miffed that there doesn't appear to be a satisfying way to resolve the ambiguity. In an ideal world, you could say: {{{#!hs bar :: forall (a :: k) (z :: F @k a). Foo z -> Int }}} But there's no visible kind application. In a fit of rage, I even tried giving kind signatures to //everything//: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where type family F (a :: k) data Foo (z :: F (a :: k)) bar :: forall (a :: k) (z :: F (a :: k)). Foo (z :: F (a :: k)) -> Int bar _ = 42 }}} But that still produces the same error. So how am I supposed to proceed from here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 14:41:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 14:41:26 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.e12f1359d249fc35ec63544f106c39d0@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | 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): You're not. Don't write a type with an ambiguous kind. :) Alternatively, and even better, implement visible kind application. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 14:55:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 14:55:45 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.bb6a3991a0b2a9b4ede977ee3a1d96c1@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | 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 RyanGlScott): OK, I found out how to do this. The trick is to make the kind of `a` in `F` visible: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where type family F a data Foo a (z :: F a) bar :: forall a (z :: F a). Foo a z -> Int bar _ = 42 }}} A similar trick works for the program in comment:1: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind data TyFun :: * -> * -> * type a ~> b = TyFun a b -> * infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 data Foo p x (z :: Apply (p :: a ~> *) (x :: a)) data Bar where MkBar :: forall a (p :: TyFun a * -> *) (x :: a) (z :: Apply p x). Foo p x z -> Bar }}} Alas, this trick doesn't scale very well to the original program, since you'd need to give `p` as a visible argument to `Sing px` somehow. (It's not clear to me if even visible kind application would fix this problem.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 15:03:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 15:03:09 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.8daf64c507fe0deeadc83c17cba3e328@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | 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 simonpj): > Should be rejected as an ambiguous occurrence site (which AllowAmbiguousTypes does not permit) rather than an ambiguous definition site (which AllowAmbiguousType does permit)? Yes. Precisely like this case: {{{ {-# LANGUAGE AllowAmbiguousTypes #-} f :: F a -> Int -- Ambiguous, but allowed because of the pragma f = e boogle :: F b -> Int boogle v = f v }}} GHC instantiates `F` at `alpha` and then complains it can't equate `F b ~ F alpha`. Visible type application is the solution. The only thing happening in this ticket is that this very same pattern is manifesting at the type level instead of the term level. Nothing more! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 15:13:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 15:13:23 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.225e6a6f9241b698b990214d7b3939ac@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | 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 RyanGlScott): OK. So after these musings about `AllowAmbiguousTypes`, kind ambiguities, and visible kind application, I've lost track if there's actually any concrete GHC bug that's manifesting in the original program. Can this be closed, or is there something left to be done? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 17:37:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 17:37:32 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.d8cc9272e227224c3333ad9ac3a81206@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: | 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 simonpj): I think that comment:6 is not a bug. I have not analysed the more complex examples. If they are the same, let's indeed close. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 18:17:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 18:17:54 -0000 Subject: [GHC] #14417: Overly specific instances may not be resolved Message-ID: <045.2f03dfc6793f9a63aacd37ac94aac70c@haskell.org> #14417: Overly specific instances may not be resolved -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE UndecidableInstances #-} class A x class A x => B x class A x => C x instance B x => C x }}} produces {{{ BrokenSuper.hs:8:10: error: • Could not deduce (A x) arising from the superclasses of an instance declaration from the context: B x bound by the instance declaration at BrokenSuper.hs:8:10-19 Possible fix: add (A x) to the context of the instance declaration • In the instance declaration for ‘C x’ | 8 | instance B x => C x }}} This was noticed in [https://stackoverflow.com/questions/47093627/can-not- deduce-superclass this SO question] and reduced by Daniel Wagner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 18:18:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 18:18:45 -0000 Subject: [GHC] #14417: Overly specific instances may not be resolved In-Reply-To: <045.2f03dfc6793f9a63aacd37ac94aac70c@haskell.org> References: <045.2f03dfc6793f9a63aacd37ac94aac70c@haskell.org> Message-ID: <060.a0d6630d86b61e8c1726de60b0487306@haskell.org> #14417: Overly specific instances may not be resolved -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 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): * Attachment "BrokenSuper.trace" added. Results of -ddump-tc-trace -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 18:27:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 18:27:21 -0000 Subject: [GHC] #14417: Overly specific instances may not be resolved In-Reply-To: <045.2f03dfc6793f9a63aacd37ac94aac70c@haskell.org> References: <045.2f03dfc6793f9a63aacd37ac94aac70c@haskell.org> Message-ID: <060.97e4100264c9baf9e17a8c195e59e793@haskell.org> #14417: Overly specific instances may not be resolved -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 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): * Attachment "BrokenSuper.cstrace" added. Results of -ddump-cs-trace -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 18:27:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 18:27:22 -0000 Subject: [GHC] #14417: Overly specific instances may not be resolved In-Reply-To: <045.2f03dfc6793f9a63aacd37ac94aac70c@haskell.org> References: <045.2f03dfc6793f9a63aacd37ac94aac70c@haskell.org> Message-ID: <060.3ca89ba514ddc684ccf92bcca2916989@haskell.org> #14417: Overly specific instances may not be resolved -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 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 RyanGlScott): This is expected behavior. From the [https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/8.0.1-notes.html#language GHC 8.0.1 release notes]: > The compiler is now a bit more conservative in solving constraints previously provided by superclasses (see Trac #11762). For instance, consider this program,: > > {{{#!hs > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE UndecidableInstances #-} > > class Super a > class (Super a) => Left a > class (Super a) => Right a > instance (Left a) => Right a -- this is now an error > }}} > > GHC now rejects this instance, claiming it cannot deduce the `Super a` superclass constraint of the `Right` typeclass. This stands in contrast to previous releases, which would accept this declaration, using the `Super a` constraint implied by the `Left a` constraint. To fix this simply add the needed superclass constraint explicitly, > > {{{#!hs > instance (Left a, Super a) => Right a > }}} In other words, it's a limitation that was imposed after the introduction of `UndecidableSuperClasses`. So from GHC's perspective, the correct thing to do here is to use this instance declaration instead: {{{#!hs instance A x => C x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 18:28:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 18:28:05 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.885fc410ed289c556f0fdacc7c71f012@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: invalid | 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 RyanGlScott): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 18:28:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 18:28:34 -0000 Subject: [GHC] #14418: Compile errors wxcore-0.92.3.0 Message-ID: <046.d5cedb927c2c2eee81fb280538ae7e8c@haskell.org> #14418: Compile errors wxcore-0.92.3.0 --------------------------------------+--------------------------------- Reporter: WinKlim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: wxcore | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I downloaded wxInstall-Achelanne-64-0.1 and started install.bat. The building of wxcore-0.92.3.0 didn't work because of compile errors, e.g. : {{{ src\haskell\Graphics\UI\WXCore\WxcTypes.hs:752:20: error: Ambiguous occurrence `CBool' It could refer to either `Foreign.C.CBool', imported from `Foreign.C' at src\haskell\Graphics\UI\WXCore\WxcTypes.hs:126:1-16 (and originally defined in `Foreign.C.Types') or `Graphics.UI.WXCore.WxcTypes.CBool', defined at src\haskell\Graphics\UI\WXCore\WxcTypes.hs:750:1 | 752 | toCBool :: Bool -> CBool }}} See attachement for full log. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 18:31:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 18:31:04 -0000 Subject: [GHC] #14418: Compile errors wxcore-0.92.3.0 In-Reply-To: <046.d5cedb927c2c2eee81fb280538ae7e8c@haskell.org> References: <046.d5cedb927c2c2eee81fb280538ae7e8c@haskell.org> Message-ID: <061.ffdc62dfc5a5dd7b2d54f36b911d130a@haskell.org> #14418: Compile errors wxcore-0.92.3.0 ---------------------------------+-------------------------------------- Reporter: WinKlim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: wxcore Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by WinKlim): Couldn't add the attachement ! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 18:32:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 18:32:24 -0000 Subject: [GHC] #14417: Overly specific instances may not be resolved In-Reply-To: <045.2f03dfc6793f9a63aacd37ac94aac70c@haskell.org> References: <045.2f03dfc6793f9a63aacd37ac94aac70c@haskell.org> Message-ID: <060.96e3b9df26df05de6392cafdb0c1509a@haskell.org> #14417: Overly specific instances may not be resolved -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11762 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => duplicate * related: => #11762 Comment: That's really quite strange, but this is clearly a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 18:55:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 18:55:05 -0000 Subject: [GHC] #14419: Check kinds for ambiguity Message-ID: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> #14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 does an ambiguity check on types. It should also do the same for kinds. Here is a program that should be rejected: {{{#!hs type family F a data T :: F a -> Type }}} `T`'s kind is ambiguous, and any occurrence of `T` will be rejected. Instead of rejecting usage sites, let's just reject the definition site. This check would be disabled by `AllowAmbiguousTypes`. Happily, I think the implementation should be easy, and that the current algorithm to check for ambiguous types should work for kinds, too. After all, types and kinds are the same these days. This was inspired by #14203, but no need to read that ticket to understand this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 18:55:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 18:55:36 -0000 Subject: [GHC] #14203: GHC-inferred type signature doesn't actually typecheck In-Reply-To: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> References: <050.d9e05c0b7ff0be338bbf3ed5e300cc6a@haskell.org> Message-ID: <065.cd94c9eabb31f916ede4ab68c6ed3afa@haskell.org> #14203: GHC-inferred type signature doesn't actually typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeInType, Resolution: invalid | 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've just created #14419 to request an ambiguity check on kinds, which may have helped Ryan not to get caught in this trap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 18:57:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 18:57:00 -0000 Subject: [GHC] #14419: Check kinds for ambiguity In-Reply-To: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> References: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> Message-ID: <062.8abf1f01e4637f30badf172b80279972@haskell.org> #14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 18:58:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 18:58:14 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.af59f296da9fa3d42961e374debe3914@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9097, 9380 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Apologies for reviving a long-dormant thread, but my understand is now that #12369 has been fixed, there is a way to achieve something like the `Any` of yore—just use a data family with a polymorphic return kind. That is: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} data family Any :: k }}} Since `Any` is a data family, it has a `Typeable` instance: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} import Type.Reflection data family Any :: k main :: IO () main = print $ typeRep @(Any :: *) }}} {{{ $ ~/Software/ghc/inplace/bin/runghc Foo.hs Any * }}} Moreover, it inhabits every kind and is a distinguishable element, so you can write things like this: {{{#!hs {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} import GHC.TypeLits import Type.Reflection data family Any :: k type family Foo (a :: Bool) :: Symbol where Foo False = "It's false" Foo Any = "It's Any" Foo True = "It's true" main :: IO () main = do print $ typeRep @(Foo False) print $ typeRep @(Foo Any) print $ typeRep @(Foo True) }}} {{{ $ ~/Software/ghc/inplace/bin/runghc Foo2.hs "It's false" "It's Any" "It's true" }}} Does this work for your use cases? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 19:13:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 19:13:15 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.9d97cfb9cedec79daa6c42236b1a79bb@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9097, 9380 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): Should work fine. Thanks! I don't do much with rank1dynamic these days though. But Edsko does. So while I was the original submitter, I'll let him close this ticket if he's happy with your solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 19:41:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 19:41:18 -0000 Subject: [GHC] #14420: Data families should not instantiate to non-Type kinds Message-ID: <047.a64d114cfae11861b31f70375118e394@haskell.org> #14420: Data families should not instantiate to non-Type kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- {{{#!hs data family Any :: k -- allowable now due to fix for #12369 type family F (a :: Bool) :: Nat where F True = 0 F False = 1 F Any = 2 }}} {{{ ghci> :kind! F True F True :: Nat = 0 ghci> :kind! F False F False :: Nat = 1 ghci> :kind! F Any F Any :: Nat = 2 }}} Oh dear. We should require that any instantiation of a data family be to a kind that ends in `Type`. Inspired by comment:31:ticket:9429 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 19:42:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 19:42:28 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.d2c8e0cec95a4da26a0747d9ef773679@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9097, 9380 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): No no no. comment:31 is an abomination. See #14420. Sorry to spoil the party here! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 21:15:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 21:15:44 -0000 Subject: [GHC] #14361: GHC HEAD miscompiles `text-containers` In-Reply-To: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> References: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> Message-ID: <057.9c4c617cff9f876db91d2da8365f1514@haskell.org> #14361: GHC HEAD miscompiles `text-containers` -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I could have sworn I had left a comment here when I looked at this last but alas it seems to be gone. Anyways, I've done a fair amount of digging on this one. I started by looking at differences in the call patterns of `Internal.$wcompareByteArray` in two compilations of the repro: one compiled with `{-# OPTIONS_GHC -fno-strictness #-}` in the `Internal2.hs` (which I'll call the "good" configuration) and one without (the "bad" configuration). Specifically I setup GDB to instrument calls to this function, logging each. This revealed that the bad configuration sometimes enters `$wcompareByteArray` with the `ofs2` and `n2` arguments being zero, where in good configuration they are non-zero. For instance, {{{#!patch --- gdb.good.log 2017-11-03 16:53:05.956764525 -0400 +++ gdb.bad.log 2017-11-03 16:53:27.481174930 -0400 @@ -186,8 +186,7 @@ done fffffffc memcmp a.len=1 a[0]=44 ofs1=0 n1=1 b.len=50 ofs2=4c n2=1 done ffffffff -memcmp a.len=1 a[0]=44 ofs1=0 n1=1 b.len=50 ofs2=4a n2=1 -done 1 +memcmp a.len=1 a[0]=44 ofs1=0 n1=1 b.len=50 ofs2=0 n2=0 memcmp a.len=1 a[0]=44 ofs1=0 n1=1 b.len=50 ofs2=4b n2=1 done 0 memcmp a.len=1 a[0]=45 ofs1=0 n1=1 b.len=50 ofs2=48 n2=1 }}} The (perhaps slightly poorly-named) `memcmp` message is emitted on entering `$wcompareByteArray`. The `done` message is emitted after the `memcmp` call returns. The fact that there is no `done` message in the bad case is the consequence of the implementation of `compareByteArray`, which skips the `memcmp` if `min n1 n2 == 0`. Another thing I have noticed is that the occurrence probability of the bug changes with GC patterns. Interestingly, it doesn't change monotonically with GC frequency; for a given value of `+RTS -A` I reproducibly get the same set of numbers on stdout. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 3 21:49:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Nov 2017 21:49:03 -0000 Subject: [GHC] #14361: GHC HEAD miscompiles `text-containers` In-Reply-To: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> References: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> Message-ID: <057.d547d47f71b017b3c281ca739fa75600@haskell.org> #14361: GHC HEAD miscompiles `text-containers` -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I should also note that the problem appears to be an interaction between the strictness signature of `Internal2.cmpBA2OfsLen` and one of the call- sites in `Data.TextSet.Unboxed.lookupIndexNear`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 4 01:07:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Nov 2017 01:07:47 -0000 Subject: [GHC] #14361: GHC HEAD miscompiles `text-containers` In-Reply-To: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> References: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> Message-ID: <057.5d5e1e19b37e212367763dc5dfbe5f9c@haskell.org> #14361: GHC HEAD miscompiles `text-containers` -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Some facts: * Allocating all `ByteArray#`s as pinned makes no difference. * Marking `TextArray.Unboxed.indexOfsLen'` as `NOINLINE` makes the problem vanish * Removing the `assert`s in `lookupIndexNear` makes no difference -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 4 11:16:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Nov 2017 11:16:00 -0000 Subject: [GHC] #14398: Fail to install haskell platform on Windows In-Reply-To: <045.d86ee14cadb946edd5536f02e4b96185@haskell.org> References: <045.d86ee14cadb946edd5536f02e4b96185@haskell.org> Message-ID: <060.0076441eb218fd2e4b74d4aee1633552@haskell.org> #14398: Fail to install haskell platform on Windows -------------------------------------+------------------------------------- Reporter: KAAAsS | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by KAAAsS): The version above works perfectly with my computer. So I tried to capture the GHCi.exe in Haskell Platform. But I could only get 2 exe. Capture file: https://1drv.ms/u/s!AsbnyYMkwdNRjFUmP4b9Sh-g2lAn Sorry for my late response. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 4 14:28:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Nov 2017 14:28:34 -0000 Subject: [GHC] #14361: GHC HEAD miscompiles `text-containers` In-Reply-To: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> References: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> Message-ID: <057.99fad0427aa8668a73b9de7113ba3049@haskell.org> #14361: GHC HEAD miscompiles `text-containers` -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): One thing that I've noticed while looking at the Core here I noticed what I believe is a slight performance papercut in our Core: In the Core we essentially have this: {{{#!hs data IdxOfsLen = IdxOfsLen !Int !Int !Int }}} Inside of `lookupIndexNear` we end up with a join point: {{{#!hs $j_sjcd [Dmd=] :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> IdxOfsLen -> LRes [LclId[JoinId(4)], Arity=4, Str=, Unf=OtherCon []] $j_sjcd (ww5_scRL [OS=OneShot] :: GHC.Prim.Int#) (ww6_scRM [OS=OneShot] :: GHC.Prim.Int#) (ww7_scRN [OS=OneShot] :: GHC.Prim.Int#) (ww4_scRK [OS=OneShot] :: IdxOfsLen Unf=OtherCon []) = case Internal2.$wcmpBA2OfsLen y_a4lB ww_sjnB ww6_scRM ww7_scRN of { LT -> Data.TextSet.Unboxed.LResBelow ww4_scRK; EQ -> Data.TextSet.Unboxed.LResExact ww4_scRK; GT -> {- some expression with no dependence on any of the above arguments -} }}} Where the call sites all look like, {{{#!hs jump $j_sjcd a b c (Internal.IdxOfsLen a b c) }}} That is, we essentially pass the same arguments twice, once unboxed and once inside a `IdxOfsLen` constructor. It seems the reason for this is that we always need the unboxed values for the call to `$wcmpBA2OfsLen` but also sometimes need the `IdxOfsLen`. It seems like it would be better to either only pass the constructor and extract the needed values out of it inside the join point, or to only pass the unboxed arguments, and construct the constructor when needed. I doubt this makes much of a difference in this particular case, but I suspect there are others where it will matter quite a bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 4 14:56:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Nov 2017 14:56:24 -0000 Subject: [GHC] #14421: LambdaCase should be suggested if it is used but not enabled Message-ID: <051.24fcb86d3a9d3d4f977ebf559dffdcb9@haskell.org> #14421: LambdaCase should be suggested if it is used but not enabled -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 try to make a multiparameter typeclass GHC (well, GHCi here) advises me to turn on {{{MultiParamTypeClasses}}} {{{ Prelude> class C a b where ... (Use MultiParamTypeClasses to allow multi-parameter classes) }}} But if I try to use {{{\case}}} it doesn't give me a helpful suggestion {{{ Prelude> :t \case (_,_) -> () :1:2: error: parse error on input ‘case’ }}} Could it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 4 15:00:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Nov 2017 15:00:36 -0000 Subject: [GHC] #14361: GHC HEAD miscompiles `text-containers` In-Reply-To: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> References: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> Message-ID: <057.f211d85b2f3e8dfe566e1c09f0fe32b2@haskell.org> #14361: GHC HEAD miscompiles `text-containers` -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Another microoptimization that might be interesting to investigate is to try being a bit more clever when generating code for things like (where the type of `expr` is an enumeration), {{{ case expr of A -> SomeCaf B -> SomeCaf' C -> SomeCaf'' ... }}} Currently we branch on the tag of `expr` to one of a set of a continuations, all of which simply load the result and return. One could eliminate the branches by instead loading the continuation from a table and returning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 4 18:06:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Nov 2017 18:06:41 -0000 Subject: [GHC] #12199: GHC is oblivious to injectivity when solving an equality constraint In-Reply-To: <050.8b18860f28fadb7400553ef29ec1b26c@haskell.org> References: <050.8b18860f28fadb7400553ef29ec1b26c@haskell.org> Message-ID: <065.f0ec58ffdea0c1a44402e61de5f2b8c6@haskell.org> #12199: GHC is oblivious to injectivity when solving an equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeFamilies, Resolution: duplicate | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10833 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate Comment: This is really a duplicate of #10833. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 4 18:50:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Nov 2017 18:50:50 -0000 Subject: [GHC] #14418: Compile errors wxcore-0.92.3.0 In-Reply-To: <046.d5cedb927c2c2eee81fb280538ae7e8c@haskell.org> References: <046.d5cedb927c2c2eee81fb280538ae7e8c@haskell.org> Message-ID: <061.b5d4c5e5ab53073227946bb377d46bb9@haskell.org> #14418: Compile errors wxcore-0.92.3.0 ---------------------------------+-------------------------------------- Reporter: WinKlim | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: wxcore Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => invalid Comment: This isn't a compiler bug. It's an issue with the library code. You should report it to the bug tracker of the project you're using. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 4 19:16:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Nov 2017 19:16:32 -0000 Subject: [GHC] #12119: Can't create injective type family equation with TypeError as the RHS In-Reply-To: <050.21d4af732cea81fafcb58c894bb8137c@haskell.org> References: <050.21d4af732cea81fafcb58c894bb8137c@haskell.org> Message-ID: <065.3b38f84415807e9e7d526c9e2045d709@haskell.org> #12119: Can't create injective type family equation with TypeError as the RHS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: wontfix | CustomTypeErrors, TypeFamilies, | InjectiveFamilies 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 RyanGlScott): * status: new => closed * resolution: => wontfix Comment: It just occurred to me that the entire premise of this ticket is wrong. I claimed: Replying to [ticket:12119 RyanGlScott]: > For the longest time, I've wanted to make a type family like this injective: > > {{{#!hs > type family Foo (a :: *) :: * where > Foo Bar = Int > Foo Baz = Char > }}} > > But the problem is that `Foo` is defined on //all// types of kind `*`, so the above definition is inherently non-injective. But the "inherently non-injective" part is totally bogus! In fact, as the code below demonstrates, `Foo` can be made injective quite easily: {{{#!hs {-# LANGUAGE TypeFamilyDependencies #-} data Bar data Baz type family Foo (a :: *) = (r :: *) | r -> a where Foo Bar = Int Foo Baz = Char }}} I don't know why I believed that crazy misconception about injectivity //vis-à-vis// exhaustivity, but in any case, the entire reason why I was pursuing this feature in the first place has vanished. In light of this, I don't think it's worth adding this much extra complexity to the type family injectivity checker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 4 20:54:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Nov 2017 20:54:06 -0000 Subject: [GHC] #14366: Type family equation refuses to unify wildcard type patterns In-Reply-To: <050.99fc7b3497a7cbec29b57a49c9d2896b@haskell.org> References: <050.99fc7b3497a7cbec29b57a49c9d2896b@haskell.org> Message-ID: <065.6966b8c46e50425e38a2bf154bd60af3@haskell.org> #14366: Type family equation refuses to unify wildcard type patterns -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeFamilies, Resolution: | TypeInType 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 RyanGlScott): Here's a much simpler example that is rejected due to this limitation: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where type family F (a :: *) :: * where F (a :: _) = a }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:5:5: error: • Expected a type, but ‘a’ has kind ‘_’ • In the first argument of ‘F’, namely ‘(a :: _)’ In the type family declaration for ‘F’ | 5 | F (a :: _) = a | ^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 4 22:23:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Nov 2017 22:23:59 -0000 Subject: [GHC] #11267: Can't parse type with kind ascription with GHCi's :kind command In-Reply-To: <050.9aff3718496dce11b98c0da6ef9544c9@haskell.org> References: <050.9aff3718496dce11b98c0da6ef9544c9@haskell.org> Message-ID: <065.129cb900def3b66a22bc078e244ed47e@haskell.org> #11267: Can't parse type with kind ascription with GHCi's :kind command -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8708 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #8708 Comment: This is a duplicate of #8708. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 4 22:24:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Nov 2017 22:24:28 -0000 Subject: [GHC] #8708: Kind annotation in tuple not parsed In-Reply-To: <047.7299eca00fb25a2e788e2c82e2894717@haskell.org> References: <047.7299eca00fb25a2e788e2c82e2894717@haskell.org> Message-ID: <062.f4b3738d3f7de7ae9c7de81323698ec9@haskell.org> #8708: Kind annotation in tuple not parsed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11267, #11622 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #11267, #11622 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 4 22:43:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Nov 2017 22:43:46 -0000 Subject: [GHC] #14361: GHC HEAD miscompiles `text-containers` In-Reply-To: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> References: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> Message-ID: <057.e0558972509db66deb91c69d5f684a69@haskell.org> #14361: GHC HEAD miscompiles `text-containers` -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, the problem was overzealous CBE due to a bug. See Phab:D4152. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 4 22:45:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Nov 2017 22:45:02 -0000 Subject: [GHC] #14361: GHC HEAD miscompiles `text-containers` In-Reply-To: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> References: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> Message-ID: <057.49eee305e3d9352692d405aecaa3ef4b@haskell.org> #14361: GHC HEAD miscompiles `text-containers` -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 5 00:36:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Nov 2017 00:36:59 -0000 Subject: [GHC] #14396: Hs-boot woes during family instance consistency checks In-Reply-To: <046.2ccc4fa31be03dddd3503a257243a5e2@haskell.org> References: <046.2ccc4fa31be03dddd3503a257243a5e2@haskell.org> Message-ID: <061.74c88b5145c578b70b0afc4c5f497e44@haskell.org> #14396: Hs-boot woes during family instance consistency checks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot 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): I will give it an attempt :) (This is an obvious way how to do it, but we don't do it this way, which makes me wonder if there isn't some lurking hazard.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 5 01:19:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Nov 2017 01:19:23 -0000 Subject: [GHC] #14422: {-# complete #-} should be able to be at least partially type directed Message-ID: <045.e6d8c3eda4338b1c4d9f477501d2f5bd@haskell.org> #14422: {-# complete #-} should be able to be at least partially type directed -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 8779 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The fact that `{-# complete #-}` pragma that was added in#8779 is tied to the set of patterns only and not the types involved can make it rather awkward or impossible to use in practice. Say I have a bunch of types that happen to share a common `(:<)` and `Empty` pattern, for views. I'd like to be able to say that for one particular type `{-# complete (:<), Empty #-}` holds, but since both aren't defined in the same module and neither one mentions my type, I'm stuck in the same `-Wno-incomplete-patterns` mess I was in before. I cant move the pragma to the individual view patterns because in general they aren't known to be a complete pattern set. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 5 01:32:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Nov 2017 01:32:36 -0000 Subject: [GHC] #14423: {-# complete #-} should be able to handle | like {-# minimal #-} Message-ID: <045.c9e8e08594a086cd0ba24a41540031ff@haskell.org> #14423: {-# complete #-} should be able to handle | like {-# minimal #-} -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 8779 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It'd be really convenient to be able to specify these like we can with `minimal` pragmas, mixing ands and ors. I wind up with a combinatorial explosion of such annotations for the cases where it works when I have large numbers of patterns. I have at least one use case where something that would be a trivial pattern to express with one (complicated) expression involving `|` becomes 64 lines of complete pragmas, and every time I extend it this count doubles. Consider what happens if you add a mix of actual and smart views of a data type: {{{#!hs {-# language ViewPatterns, PatternSynonyms, GeneralizedNewtypeDeriving #-} newtype Delta = Delta Int deriving (Eq,Num) instance Monoid Delta where mempty = 0 mappend = (+) data Exp = Var !Int | AP !Delta !Exp !Exp | LAM !Delta !Exp rel 0 xs = xs rel d (AP d' l r) = AP (d + d') l r rel d (LAM d' b) = LAM (d + d') b rel _ (Var n) = Var n pattern Ap a b <- AP d (rel d -> a) (rel d -> b) where Ap a b = AP 0 a b pattern Lam b <- LAM d (rel d -> b) where Lam b = LAM 0 b {-# complete Var, AP, Lam #-} {-# complete Var, Ap, LAM #-} {-# complete Var, AP, LAM #-} }}} Every data constructor I add with a smart view adds to the powerset of complete pragmas I should supply. On the other hand with `|` patterns: {{{#!hs {-# complete Var, (Ap | AP), (Lam | LAM) #-} }}} extends linearly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 5 07:10:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Nov 2017 07:10:29 -0000 Subject: [GHC] #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.ff34354a9317df7b68eafde9b1a4f27a@haskell.org> #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context -------------------------------------+------------------------------------- Reporter: cactus | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: | -------------------------------------+------------------------------------- Comment (by AntC): To heap a few more straws on this camel's back ... Pattern synonym used in an expression context could act as a smart constructor; and be used in a pattern context just for matching. {{{ data Dumb = Dumb Int pattern {-# SMARTCONSTRUCTOR #-} Smart { nonneg } | nonneg >= 0 = Dumb nonneg -- or perhaps for better error messages pattern {-# SMARTCONSTRUCTOR #-} Smart { nonneg } = assert (nonneg >= 0) $ Dumb nonneg }}} The downsides of a function-as-smart-constructor are: * You can only use the function in an expression context. * The function can't have named fields like a proper constructor. * The function can't be used for pattern match. * For pattern match, you can't allow the underlying data constructor to be in scope, for fear of abuse/breaking the type's invariant. * So you can't allow the underlying data constructor to appear in a pattern match, even though that would be safe. * Then you must define a unidirectional pattern synonym to support pattern match but not construction. * So now you've got an ugly set of module exports to provide the right name scoping: expose smart constructor function, pattern constructor and field labels; hide underlying constructor. Functions as smart constructors are not so smart, as a quick perusal of StackOverflow will show you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 5 14:19:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Nov 2017 14:19:01 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled In-Reply-To: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> References: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> Message-ID: <062.75a84090e4ff358e356ad5f4fca0d35d@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Fuuzetsu): Let me know if there's any information I can provide to help debug this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 5 16:39:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Nov 2017 16:39:35 -0000 Subject: [GHC] #14331: Overzealous free-floating kind check causes deriving clause to be rejected In-Reply-To: <050.cb87f2a10e38fd0ac57d92b074ac5d5b@haskell.org> References: <050.cb87f2a10e38fd0ac57d92b074ac5d5b@haskell.org> Message-ID: <065.7ff3998f042bc0abf7371cf1b60bab29@haskell.org> #14331: Overzealous free-floating kind check causes deriving clause to be rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14331 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I made an attempt towards fixing this at https://github.com/RyanGlScott/ghc/tree/rgs/T14331. I didn't get very far. My first goal was to switch over from the use of the pure unifier to the monadic one, but that alone proves to be quite difficult. The problem is that for some strange reason, using the monadic unifier causes several type variables to be filled in with `Any`, leading to Core Lint errors and general badness. As one example, if you compile this program: {{{#!hs module Bug where data Pair a b = Pair a b deriving Eq }}} Using my branch with `-dcore-lint` on, you'll be greeted with this: {{{ $ ghc/inplace/bin/ghc-stage2 --interactive Bug.hs -dcore-lint GHCi, version 8.3.20171031: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) *** Core Lint errors : in result of Desugar (after optimization) *** Bug.hs:4:12: warning: [RHS of $fEqPair :: forall a b. (Eq Any, Eq Any) => Eq (Pair Any Any)] The type of this binder doesn't match the type of its RHS: $fEqPair Binder's type: forall a b. (Eq Any, Eq Any) => Eq (Pair Any Any) Rhs type: forall a b. (Eq b, Eq a) => Eq (Pair a b) *** Offending Program *** $c==_a2Cw :: forall a b. (Eq b, Eq a) => Pair a b -> Pair a b -> Bool [LclId] $c==_a2Cw = \ (@ a_a2Cr) (@ b_a2Cs) ($dEq_a2Ct :: Eq b_a2Cs) ($dEq_a2Cu :: Eq a_a2Cr) (ds_d2Dz :: Pair a_a2Cr b_a2Cs) (ds_d2DA :: Pair a_a2Cr b_a2Cs) -> case ds_d2Dz of { Pair a1_a2Cn a2_a2Co -> case ds_d2DA of { Pair b1_a2Cp b2_a2Cq -> && (== @ a_a2Cr $dEq_a2Cu a1_a2Cn b1_a2Cp) (== @ b_a2Cs $dEq_a2Ct a2_a2Co b2_a2Cq) } } Rec { $fEqPair [InlPrag=NOUSERINLINE CONLIKE] :: forall a b. (Eq Any, Eq Any) => Eq (Pair Any Any) [LclIdX[DFunId], Unf=DFun: \ (@ a_a2z3[tau:1]) (@ b_a2z4[tau:1]) (v_B1 :: Eq b_a2z4[tau:1]) (v_B2 :: Eq a_a2z3[tau:1]) -> C:Eq TYPE: Pair a_a2z3[tau:1] b_a2z4[tau:1] $c==_a2Cw @ a_a2z3[tau:1] @ b_a2z4[tau:1] v_B1 v_B2 $c/=_a2CF @ a_a2z3[tau:1] @ b_a2z4[tau:1] v_B1 v_B2] $fEqPair = \ (@ a_a2Cr) (@ b_a2Cs) ($dEq_a2Ct :: Eq b_a2Cs) ($dEq_a2Cu :: Eq a_a2Cr) -> C:Eq @ (Pair a_a2Cr b_a2Cs) ($c==_a2Cw @ a_a2Cr @ b_a2Cs $dEq_a2Ct $dEq_a2Cu) ($c/=_a2CF @ a_a2Cr @ b_a2Cs $dEq_a2Ct $dEq_a2Cu) $c/=_a2CF [Occ=LoopBreaker] :: forall a b. (Eq b, Eq a) => Pair a b -> Pair a b -> Bool [LclId] $c/=_a2CF = \ (@ a_a2Cr) (@ b_a2Cs) ($dEq_a2Ct :: Eq b_a2Cs) ($dEq_a2Cu :: Eq a_a2Cr) -> $dm/= @ (Pair a_a2Cr b_a2Cs) ($fEqPair @ a_a2Cr @ b_a2Cs $dEq_a2Ct $dEq_a2Cu) end Rec } $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Bug"#) $krep_a2Dx [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a2Dx = $WKindRepVar (I# 1#) $krep_a2Dv [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a2Dv = $WKindRepVar (I# 0#) $tcPair :: TyCon [LclIdX] $tcPair = TyCon 13156152634686180623## 12550973000996521707## $trModule (TrNameS "Pair"#) 0# krep$*->*->* $krep_a2Dy [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a2Dy = KindRepTyConApp $tcPair (: @ KindRep $krep_a2Dv (: @ KindRep $krep_a2Dx ([] @ KindRep))) $krep_a2Dw [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a2Dw = KindRepFun $krep_a2Dx $krep_a2Dy $krep_a2Du [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a2Du = KindRepFun $krep_a2Dv $krep_a2Dw $tc'Pair :: TyCon [LclIdX] $tc'Pair = TyCon 13419949030541524809## 8448108315116356699## $trModule (TrNameS "'Pair"#) 2# $krep_a2Du *** End of Offense *** : error: Compilation had errors *** Exception: ExitFailure 1 }}} I've tried various combinations of `zonkTcTypes` and `zonkTcTypeToTypes`, but none of them work, so I'm thoroughly stuck here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 5 19:29:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Nov 2017 19:29:07 -0000 Subject: [GHC] #14424: lcm :: Word -> Word -> Word is not specialised Message-ID: <047.63414eee7322738e08b3c70ef95b2d25@haskell.org> #14424: lcm :: Word -> Word -> Word is not specialised -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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.Real` defines `gcd` with two specialised versions `gcdInt'` and `gcdWord'` and rules {{{ {-# RULES "gcd/Int->Int->Int" gcd = gcdInt' "gcd/Word->Word->Word" gcd = gcdWord' #-} }}} It also defines `lcm x y = abs ((x `quot` (gcd x y)) * y)`, but specialises it only for `Int`: {{{ {-# SPECIALISE lcm :: Int -> Int -> Int #-} }}} So `lcm :: Int -> Int -> Int` will be compiled to a nice and fast `gcdInt'`, but `lcm :: Word -> Word -> Word` will not benefit from the existence of `gcdWord'`. This leads to a huge performance gap, about 8x. Here is a test program: {{{ module Main where import Data.Time.Clock main :: IO () main = do t0 <- getCurrentTime print $ maximum $ [ lcm x y | x <- [1..1000 :: Int], y <- [1..1000 :: Int] ] t1 <- getCurrentTime putStrLn "lcm :: Int -> Int -> Int" print $ diffUTCTime t1 t0 t0 <- getCurrentTime print $ maximum $ [ lcm x y | x <- [1..1000 :: Word], y <- [1..1000 :: Word] ] t1 <- getCurrentTime putStrLn "lcm :: Word -> Word -> Word" print $ diffUTCTime t1 t0 t0 <- getCurrentTime print $ maximum $ [ lcmWord x y | x <- [1..1000 :: Word], y <- [1..1000 :: Word] ] t1 <- getCurrentTime putStrLn "lcmWord :: Word -> Word -> Word" print $ diffUTCTime t1 t0 -- Similar to GHC.Real.lcm, but specialized for Word lcmWord :: Word -> Word -> Word lcmWord _ 0 = 0 lcmWord 0 _ = 0 lcmWord x y = abs ((x `quot` (gcd x y)) * y) }}} On my PC the output is: {{{ 999000 lcm :: Int -> Int -> Int 0.086963s 999000 lcm :: Word -> Word -> Word 0.591168s 999000 lcmWord :: Word -> Word -> Word 0.077644s }}} My proposal is to add a SPECIALIZE pragma to `GHC.Real`: {{{ {-# SPECIALISE lcm :: Word -> Word -> Word #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 5 19:37:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Nov 2017 19:37:52 -0000 Subject: [GHC] #14424: lcm :: Word -> Word -> Word is not specialised In-Reply-To: <047.63414eee7322738e08b3c70ef95b2d25@haskell.org> References: <047.63414eee7322738e08b3c70ef95b2d25@haskell.org> Message-ID: <062.d720476cddccf3803230347e14ed4316@haskell.org> #14424: lcm :: Word -> Word -> Word is not specialised -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Description changed by Bodigrim: Old description: > `GHC.Real` defines `gcd` with two specialised versions `gcdInt'` and > `gcdWord'` and rules > > {{{ > {-# RULES > "gcd/Int->Int->Int" gcd = gcdInt' > "gcd/Word->Word->Word" gcd = gcdWord' > #-} > }}} > > It also defines `lcm x y = abs ((x `quot` (gcd x y)) * y)`, but > specialises it only for `Int`: > {{{ > {-# SPECIALISE lcm :: Int -> Int -> Int #-} > }}} > > So `lcm :: Int -> Int -> Int` will be compiled to a nice and fast > `gcdInt'`, but `lcm :: Word -> Word -> Word` will not benefit from the > existence of `gcdWord'`. This leads to a huge performance gap, about 8x. > > Here is a test program: > > {{{ > module Main where > > import Data.Time.Clock > > main :: IO () > main = do > t0 <- getCurrentTime > print $ maximum $ [ lcm x y | x <- [1..1000 :: Int], y <- [1..1000 :: > Int] ] > t1 <- getCurrentTime > putStrLn "lcm :: Int -> Int -> Int" > print $ diffUTCTime t1 t0 > > t0 <- getCurrentTime > print $ maximum $ [ lcm x y | x <- [1..1000 :: Word], y <- [1..1000 :: > Word] ] > t1 <- getCurrentTime > putStrLn "lcm :: Word -> Word -> Word" > print $ diffUTCTime t1 t0 > > t0 <- getCurrentTime > print $ maximum $ [ lcmWord x y | x <- [1..1000 :: Word], y <- [1..1000 > :: Word] ] > t1 <- getCurrentTime > putStrLn "lcmWord :: Word -> Word -> Word" > print $ diffUTCTime t1 t0 > > -- Similar to GHC.Real.lcm, but specialized for Word > lcmWord :: Word -> Word -> Word > lcmWord _ 0 = 0 > lcmWord 0 _ = 0 > lcmWord x y = abs ((x `quot` (gcd x y)) * y) > }}} > > On my PC the output is: > > {{{ > 999000 > lcm :: Int -> Int -> Int > 0.086963s > 999000 > lcm :: Word -> Word -> Word > 0.591168s > 999000 > lcmWord :: Word -> Word -> Word > 0.077644s > }}} > > My proposal is to add a SPECIALIZE pragma to `GHC.Real`: > {{{ > {-# SPECIALISE lcm :: Word -> Word -> Word #-} > }}} New description: `GHC.Real` defines `gcd` with two specialised versions `gcdInt'` and `gcdWord'` and rules {{{ {-# RULES "gcd/Int->Int->Int" gcd = gcdInt' "gcd/Word->Word->Word" gcd = gcdWord' #-} }}} It also defines `lcm x y = abs ((x `quot` (gcd x y)) * y)`, but specialises it only for `Int`: {{{ {-# SPECIALISE lcm :: Int -> Int -> Int #-} }}} So `lcm :: Int -> Int -> Int` will be compiled to a nice and fast `gcdInt'`, but `lcm :: Word -> Word -> Word` will not benefit from the existence of `gcdWord'`. This leads to a huge performance gap, about 8x. Here is a test program: {{{ module Main where import Data.Time.Clock main :: IO () main = do t0 <- getCurrentTime print $ maximum $ [ lcm x y | x <- [1..1000 :: Int], y <- [1..1000 :: Int] ] t1 <- getCurrentTime putStrLn "lcm :: Int -> Int -> Int" print $ diffUTCTime t1 t0 t0 <- getCurrentTime print $ maximum $ [ lcm x y | x <- [1..1000 :: Word], y <- [1..1000 :: Word] ] t1 <- getCurrentTime putStrLn "lcm :: Word -> Word -> Word" print $ diffUTCTime t1 t0 t0 <- getCurrentTime print $ maximum $ [ lcmWord x y | x <- [1..1000 :: Word], y <- [1..1000 :: Word] ] t1 <- getCurrentTime putStrLn "lcmWord :: Word -> Word -> Word" print $ diffUTCTime t1 t0 -- Similar to GHC.Real.lcm, but specialized for Word lcmWord :: Word -> Word -> Word lcmWord _ 0 = 0 lcmWord 0 _ = 0 lcmWord x y = abs ((x `quot` (gcd x y)) * y) }}} On my PC the output (`ghc -O2`) is: {{{ 999000 lcm :: Int -> Int -> Int 0.086963s 999000 lcm :: Word -> Word -> Word 0.591168s 999000 lcmWord :: Word -> Word -> Word 0.077644s }}} My proposal is to add a SPECIALIZE pragma to `GHC.Real`: {{{ {-# SPECIALISE lcm :: Word -> Word -> Word #-} }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 5 20:07:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Nov 2017 20:07:32 -0000 Subject: [GHC] #14396: Hs-boot woes during family instance consistency checks In-Reply-To: <046.2ccc4fa31be03dddd3503a257243a5e2@haskell.org> References: <046.2ccc4fa31be03dddd3503a257243a5e2@haskell.org> Message-ID: <061.a666bf75c36c56e4bd405177a246e293@haskell.org> #14396: Hs-boot woes during family instance consistency checks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4154 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D4154 Comment: New patch up. Note that I haven't validated it yet, but it seems to pass the typecheck/driver tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 5 20:27:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Nov 2017 20:27:18 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled In-Reply-To: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> References: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> Message-ID: <062.99a40f5489fd221a5e1fbbcdd2553eaf@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 duog): Note that the entirety of the anomolous time is in the garbage collector. It looks to me like the program is running on only one core. If that's the case, then perhaps the garbage collector is spending entire time slices busy-waiting on a spin lock. As for why it doesn't happen while profiled, perhaps the non-profiled code has allocation-free loops, they can have poor interactions with garbage collection. Some things to try: * run the program inside `time` to verify that the numbers -s is reporting are correct * use `time` to prove that a non-haskell program is able to run on multiple cores. Sorry I don't have a one-liner for you... * try the profiled version, omitting -fprof-auto, this (should) give the same core as without -prof, and may exhibit the bad gc behaviour. * play with the -q* and -N RTS options to see if anything changes. * use https://wiki.haskell.org/ThreadScope to see exactly what the garbage collector is up to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 5 22:20:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Nov 2017 22:20:00 -0000 Subject: [GHC] #14331: Overzealous free-floating kind check causes deriving clause to be rejected In-Reply-To: <050.cb87f2a10e38fd0ac57d92b074ac5d5b@haskell.org> References: <050.cb87f2a10e38fd0ac57d92b074ac5d5b@haskell.org> Message-ID: <065.32783a30f2763f370af8f3cc7eae9c1a@haskell.org> #14331: Overzealous free-floating kind check causes deriving clause to be rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14331 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm taking a look at your work, but it would be much more ergonomic to review this in Phab. Rough comments: - Why the `newMetaTyVars` at the top? That doesn't look right to me. - You're trying to swap the `tcUnifyTy` with a `unifyType`. Good. But the `tcUnifyTy` is still there. Is this intentional or an aspect of the fact that this is w.i.p.? - Before you call `unifyType`, you need to have metavariables that `unifyType` will unify. According to comment:31, these variables should be as specified in step (h) of the algorithm. So perhaps you do need `newMetaTyVars`, but not over all the tvs, just a subset of them. - The second half of step (i) of the algorithm (skolemizing unbound metavariables) might nicely be accomplished by `quantifyTyVars`. It's a bit unclear to me without thinking more about this whether this function does too much, but its helper function `zonkQuantifiedTyVar` is definitely what you need to do. I hope this gets you going again... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 5 23:15:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Nov 2017 23:15:42 -0000 Subject: [GHC] #5889: -fno-prof-count-entries leads to linking errors In-Reply-To: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> References: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> Message-ID: <058.1fa57a2ff8b7178a0574ac1d7862e381@haskell.org> #5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): See Phab:D4158 for a testcase that demonstrates this. Replying to [comment:13 simonpj]: > > However, the tick remains in the unfolding > > * Why? If it is dropped in the RHS why isn't it dropped in the unfolding too? At the risk of stating the obvious, because the tick is around a `Case`, not a `Var`. > > * Also, when that unfolding is later inlined at a call site, why isn't the tick eliminated then? My test case illustrates an example of this, hopefully it is clear from the comments what is going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 5 23:52:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Nov 2017 23:52:17 -0000 Subject: [GHC] #14420: Data families should not instantiate to non-Type kinds In-Reply-To: <047.a64d114cfae11861b31f70375118e394@haskell.org> References: <047.a64d114cfae11861b31f70375118e394@haskell.org> Message-ID: <062.9039c34cd85113dde6a2a14b309856f0@haskell.org> #14420: Data families should not instantiate to non-Type kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) Comment: Hope this won't affect #12369, interestingly your [https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1075&context=compsci_pubs Constrained Type Families] paper doesn't mention constraining data families.. But if we require all data families to be associated {{{#!hs class CAny k where data Any :: k }}} then using `Any :: Bool` as a case in the type family `F` will create a `CAny Bool` constraint, we are already barred from actually defining `data instance Any :: Bool`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 02:42:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 02:42:46 -0000 Subject: [GHC] #14425: approxRational is wrong when (rat - eps) overflows in negative direction Message-ID: <046.eb71da6200dae7e365172a0968ad4790@haskell.org> #14425: approxRational is wrong when (rat - eps) overflows in negative direction -------------------------------------+------------------------------------- Reporter: danielk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.1 libraries/base | 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: -------------------------------------+------------------------------------- This program is wrong. The second output should be 0 % 1. {{{ import Data.Ratio main = do print (approxRational (0 % 1 :: Ratio Int) (1 % 10)) -- 0%1, correct print (approxRational (0 % 1 :: Ratio Word) (1 % 10)) -- 1%1, incorrect }}} The problem is that (rat-eps) overflows in the negative direction (see [http://hackage.haskell.org/package/base-4.10.0.0/docs/src/Data.Ratio.html#approxRational source]). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 02:50:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 02:50:03 -0000 Subject: [GHC] #14420: Data families should not instantiate to non-Type kinds In-Reply-To: <047.a64d114cfae11861b31f70375118e394@haskell.org> References: <047.a64d114cfae11861b31f70375118e394@haskell.org> Message-ID: <062.de98919324ac3dad12332c66aa2810f0@haskell.org> #14420: Data families should not instantiate to non-Type kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 goldfire): Yes, that paper silently ignored data families, but I've thought all along (well, at least since I started thinking about constrained type families) that they should be associated, too. They're simpler because there are no closed data families. Chalk this up as yet another problem the constrained type families approach would solve... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 03:00:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 03:00:21 -0000 Subject: [GHC] #14425: approxRational is wrong when (rat - eps) overflows in negative direction In-Reply-To: <046.eb71da6200dae7e365172a0968ad4790@haskell.org> References: <046.eb71da6200dae7e365172a0968ad4790@haskell.org> Message-ID: <061.64363def72c18e5c0634b312b9534d7d@haskell.org> #14425: approxRational is wrong when (rat - eps) overflows in negative direction -------------------------------------+------------------------------------- Reporter: danielk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danielk): I suggest the following simple fix. Convert rat and eps to Rational before subtracting and adding epsilon. This eliminates the possibility of overflow (in either direction). {{{ approxRational :: (RealFrac a) => a -> a -> Rational approxRational rat eps = simplest (toRational rat - toRational eps) (toRational rat + toRational eps) ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 06:14:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 06:14:17 -0000 Subject: [GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends In-Reply-To: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> References: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> Message-ID: <060.79b9fe193553a6d9d924f5f01ed22540@haskell.org> #14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: ghc-pkg | Version: 8.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): Phab:D4159 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D4159 * milestone: 8.4.1 => 8.2.3 Comment: It'd be nice to get this into the 8.2 branch and the backport is fairly easy; so if there's an 8.2.3, I'd like to queue this patch for its release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 07:02:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 07:02:59 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.f3cd4cbf2ae3e14a760240e76a546d57@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: core-lint | case Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4160 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D4160 Comment: I put up a differential to just strip the tests out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 08:38:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 08:38:45 -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.719faa2fd4616cf65841513ac539cc30@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I wonder if ekmett's problem lies in the somewhat bogus type family definition: {{{#!hs type family Gcd :: Nat -> Nat -> Nat }}} An instance of the family would have to be a ''constructor'' of kind `Nat -> Nat -> Nat`. There is no such thing, so GHC may reject the notion under some circumstances. This is just speculation, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 08:39:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 08:39:06 -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.f62062e5e0f5dc5d78c9ea787e8cec32@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 08:55:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 08:55:21 -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.9895e2022bdfc5d5d7c72a9540738c79@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Here's a much smaller reproduction of what I suspect is going on in Edward's code: {{{#!hs {-# language DataKinds #-} {-# language TypeFamilies #-} {-# language TypeOperators #-} module T11066 where import Data.Type.Equality import GHC.TypeLits (Nat) type family Gcd :: Nat -> Nat -> Nat foo :: 1 :~: Gcd 3 4 -> () foo Refl = () }}} This produces {{{ T11066.hs:11:5: error: • Couldn't match type ‘Gcd 3 4’ with ‘1’ Inaccessible code in a pattern with constructor: Refl :: forall k (a :: k). a :~: a, in an equation for ‘foo’ • In the pattern: Refl In an equation for ‘foo’: foo Refl = () | 11 | foo Refl = () | }}} even though someone could easily `unsafeCoerce` their way into `1 :~: Gcd 3 4`. My hypothesis about the type family is supported by the fact that changing `Gcd` to {{{#!hs type family Gcd (a :: Nat) (b :: Nat) :: Nat }}} makes the problem go away. But I suspect ekmett needs the original version to be able to perform symbolic calculations on `Gcd`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 09:44:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 09:44:44 -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.5e941744d77f1f61eeeaa395f792890c@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Actually, I take that last bit back. Does Ed need the original version of `Gcd`, or will the more legitimate version work in this context? I don't see how he can really take advantage of the former, but I could be missing something; it's late. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 10:06:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 10:06:41 -0000 Subject: [GHC] #14419: Check kinds for ambiguity In-Reply-To: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> References: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> Message-ID: <062.6db88a286994495556020179a11184e4@haskell.org> #14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType 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): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 10:31:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 10:31:25 -0000 Subject: [GHC] #1460: Problem with Monoid instance of Data.Map In-Reply-To: <051.14fc774a6009986dddf4bde26633711e@haskell.org> References: <051.14fc774a6009986dddf4bde26633711e@haskell.org> Message-ID: <066.869125776a1c1dc772930d6c7ecceebe@haskell.org> #1460: Problem with Monoid instance of Data.Map -------------------------------------+------------------------------------- Reporter: ahey@… | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Resolution: fixed | Keywords: Data.Map | Monoid 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 txnull): I find both instances useful. Maybe there should not be a instance at all and everybody has to create one as needed or create both using newtypes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 10:39:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 10:39:57 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.62225f9767689680cfc4ca55c2063be8@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11706 | Differential Rev(s): Phab:D1219 Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): Submitted a proposal: https://github.com/ghc-proposals/ghc- proposals/pull/90. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 10:42:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 10:42:51 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.690901c6ef817dbb2ddfe52cb26d6865@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11706 | Differential Rev(s): Phab:D1219 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mentheta): Thank you akio! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 11:13:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 11:13:10 -0000 Subject: [GHC] #14420: Data families should not instantiate to non-Type kinds In-Reply-To: <047.a64d114cfae11861b31f70375118e394@haskell.org> References: <047.a64d114cfae11861b31f70375118e394@haskell.org> Message-ID: <062.b9b6671bdc2afd39469a3cef3d63f4f8@haskell.org> #14420: Data families should not instantiate to non-Type kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: TypeInType 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): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 11:16:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 11:16:18 -0000 Subject: [GHC] #14361: GHC HEAD miscompiles `text-containers` In-Reply-To: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> References: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> Message-ID: <057.4d6810a51eba1b6e40f16af563ce4579@haskell.org> #14361: GHC HEAD miscompiles `text-containers` -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Crumbs. From Phab:D4152: {{{ Previously CBE computed equality by taking the lists of middle nodes of the blocks being compared and zipping them together. It would then map over this list with the equality relation, and accumulate the result. However, this is completely wrong: Consider what will happen when we compare a block with no middle nodes with one with one or more. The result of zip will be empty and consequently the pass may conclude that the two are indeed equivalent (if their last nodes also match). }}} That's truly terrible! Well caught. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 11:17:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 11:17:41 -0000 Subject: [GHC] #14361: GHC HEAD miscompiles `text-containers` In-Reply-To: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> References: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> Message-ID: <057.d60b552fc4a1bbc2cc05180666f4871d@haskell.org> #14361: GHC HEAD miscompiles `text-containers` -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > It seems like it would be better to either only pass the constructor and extract the needed values out of it inside the join point, or to only pass the unboxed arguments, and construct the constructor when needed. It's indeed not clear which is best. It's a conscious choice though; see `Note [Case binders and join points]` in `Simplify.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 11:37:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 11:37:07 -0000 Subject: [GHC] #14423: {-# complete #-} should be able to handle | like {-# minimal #-} In-Reply-To: <045.c9e8e08594a086cd0ba24a41540031ff@haskell.org> References: <045.c9e8e08594a086cd0ba24a41540031ff@haskell.org> Message-ID: <060.29ad8c103ccc7d05607bc77214d00f47@haskell.org> #14423: {-# complete #-} should be able to handle | like {-# minimal #-} -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8779 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 11:37:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 11:37:28 -0000 Subject: [GHC] #14422: {-# complete #-} should be able to be at least partially type directed In-Reply-To: <045.e6d8c3eda4338b1c4d9f477501d2f5bd@haskell.org> References: <045.e6d8c3eda4338b1c4d9f477501d2f5bd@haskell.org> Message-ID: <060.cd733f08f8c5f6faf0354a1a858e63dc@haskell.org> #14422: {-# complete #-} should be able to be at least partially type directed -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8779 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 11:49:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 11:49:36 -0000 Subject: [GHC] #14424: lcm :: Word -> Word -> Word is not specialised In-Reply-To: <047.63414eee7322738e08b3c70ef95b2d25@haskell.org> References: <047.63414eee7322738e08b3c70ef95b2d25@haskell.org> Message-ID: <062.dc5f5c536f94336cac8b9c83fcc39acd@haskell.org> #14424: lcm :: Word -> Word -> Word is not specialised -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): > My proposal is to add a SPECIALIZE pragma to GHC.Real: Fine with me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 12:11:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 12:11:41 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.e28b2608327ae4e9acaea1ef1bbd2a8b@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): * Attachment "stgVarsSizeRatio.png" added. Free variables / other STG ratio -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 12:18:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 12:18:12 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.504d9e1c5eaaf9c317e0883fdb22af9a@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): Here's some tentative evidence: [[Image(https://ghc.haskell.org/trac/ghc/attachment/ticket/7258/stgVarsSizeRatio.png)]] The 3 misbehaving examples (read, show, and to a lesser degree read-appl) show linear growth of the free-variables/other-stg ratio (which suggests roughly quadratic growth of the size of the overall STG size, assuming linear growth of the base STG size), while the well-behaved examples maintain a more-or-less constant ratio. The full profiling job (up to 400 fields) is still running, but this small sample (50, 100 and 150 fields) looks pretty convincing to me already. A quick glance at the generated STG suggests that there is indeed some deep nesting of closures going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 13:09:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 13:09:03 -0000 Subject: [GHC] #14425: approxRational is wrong when (rat - eps) overflows in negative direction In-Reply-To: <046.eb71da6200dae7e365172a0968ad4790@haskell.org> References: <046.eb71da6200dae7e365172a0968ad4790@haskell.org> Message-ID: <061.18bd6425d0c5b9df598ff9db4fec7120@haskell.org> #14425: approxRational is wrong when (rat - eps) overflows in negative direction -------------------------------------+------------------------------------- Reporter: danielk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vilem): +1 This caused a very hard-to-find bug in my code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 13:15:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 13:15:05 -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.90f71c9ec749b88b195c5b89301ba1e0@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Here's a much smaller reproduction of what I suspect is going on in Edward's code I don't see the problem here. As stated, `Gcd` is a nullary type function, so it's definitely the case that `1 :~: Gcd 3 4` is unsatisfiable, so `foo` cannot be called. Why is it wrong for GHC to complain. I'm really lost in this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 13:21:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 13:21:16 -0000 Subject: [GHC] #14396: Hs-boot woes during family instance consistency checks In-Reply-To: <046.2ccc4fa31be03dddd3503a257243a5e2@haskell.org> References: <046.2ccc4fa31be03dddd3503a257243a5e2@haskell.org> Message-ID: <061.9eea63aeb0d073cd9cb49ab655e5cd1f@haskell.org> #14396: Hs-boot woes during family instance consistency checks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4154 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That sounds good. I suppose the worry is that, in Core, we might end up with something like {{{ case x of A -> e1 B -> e2 }}} but find that `x :: T` and `T` is abstract (because it somehow came from the hs-boot file), whereas `T` is defined in this module with constructors `A` and `B`. I can't see how this (or something like it) could happen; but I'm not sure how to convince ourselves that this can't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 13:45:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 13:45:14 -0000 Subject: [GHC] #14424: lcm :: Word -> Word -> Word is not specialised In-Reply-To: <047.63414eee7322738e08b3c70ef95b2d25@haskell.org> References: <047.63414eee7322738e08b3c70ef95b2d25@haskell.org> Message-ID: <062.f4398baffee957120ba1a37e3f65f6df@haskell.org> #14424: lcm :: Word -> Word -> Word is not specialised -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 RyanGlScott): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 13:57:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 13:57:20 -0000 Subject: [GHC] #14339: GHC 8.2.1 regression when combining GND with TypeError (solveDerivEqns: probable loop) In-Reply-To: <050.71c0075dc8f8df8e6578520d1b23a3ca@haskell.org> References: <050.71c0075dc8f8df8e6578520d1b23a3ca@haskell.org> Message-ID: <065.de6e885edf19fcc737b80e1efd7ffbe9@haskell.org> #14339: GHC 8.2.1 regression when combining GND with TypeError (solveDerivEqns: probable loop) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.3 Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: deriving, Resolution: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | testsuite/tests/deriving/should_compile/T14339 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.4.1 => 8.2.3 Comment: This was marked as merge with no release target, so I'll optimistically assume you meant 8.2.3, if there is one planned. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 14:05:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 14:05:17 -0000 Subject: [GHC] #14331: Overzealous free-floating kind check causes deriving clause to be rejected In-Reply-To: <050.cb87f2a10e38fd0ac57d92b074ac5d5b@haskell.org> References: <050.cb87f2a10e38fd0ac57d92b074ac5d5b@haskell.org> Message-ID: <065.c9cfc9f6cb5efac2e148e2101217f915@haskell.org> #14331: Overzealous free-floating kind check causes deriving clause to be rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14331 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I posted this to a branch instead of Phab per SPJ's request, since he says he finds that easier to navigate to Phab. As far as `newMetaTyVars` goes: yes, I'm aware that I needn't call `newMetaTyVars` on //everything// in `tvs`. As I mentioned, I'm taking this piece-by-piece, and I wanted to get the simple case where the `deriving` clause mentions no variables working first before I add additional complexity on top (especially since the simple case is proving to be so difficult). I still need the `tcUnifyTy` because of this validity check: https://github.com/RyanGlScott/ghc/commit/d8ed9e57ecc60a78321ab10b02f6387759d2c82e #diff-6ce1356ff43cc56932867d6f6b63d7dcR718 I'm quite confused at all the different variants of of `zonkWibbleWobble` out there. There's `zonkTcType` and `zonkTcTypeToType` for starters (whose simultaneous existence still baffles me), and now there's `zonkQuantifiedTyVar` and `zonkTyBndrX`‽ How is someone like me who isn't in the loop supposed to be able to discern all of these little idiosyncrasies? (Sorry, rant over. I frequently get overwhelmed at all of the arcane knowledge one needs to make simple changes to the typechecker.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 14:30:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 14:30:22 -0000 Subject: [GHC] #14422: {-# complete #-} should be able to be at least partially type directed In-Reply-To: <045.e6d8c3eda4338b1c4d9f477501d2f5bd@haskell.org> References: <045.e6d8c3eda4338b1c4d9f477501d2f5bd@haskell.org> Message-ID: <060.9bcb281fdcc08770b548a894063e97ab@haskell.org> #14422: {-# complete #-} should be able to be at least partially type directed -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8779 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 15:06:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 15:06:28 -0000 Subject: [GHC] #14426: Inferred type not principle/most general? Message-ID: <051.592e64f83e53fe7f919c84659111f8d5@haskell.org> #14426: Inferred type not principle/most general? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 type inferred for `(#)` is `H a a -> H a a -> H a a` (from [https://arxiv.org/pdf/1309.5135.pdf Coroutining Folds with Hyperfunctions]) {{{#!hs newtype H a b = Fn { invoke :: H b a -> b } -- ( # ) :: H a a -> H a a -> H a a f # g = Fn (\k -> invoke f (g # k)) }}} but a more general type is actually {{{#!hs ( # ) :: H b c -> H a b -> H a c f # g = Fn (\k -> invoke f (g # k)) }}} Is this expected or a blind spot in type inference ---- Same thing in ''ghci'' {{{ $ ghci -ignore-dot-ghci GHCi, version 8.3.20170920: http://www.haskell.org/ghc/ :? for help Prelude> :set prompt "> " > > newtype H a b = Fn { invoke :: H b a -> b } > > f # g = Fn (\k -> invoke f (g # k)) > :t ( # ) ( # ) :: H a a -> H a a -> H a a > > let ( # ) :: H b c -> H a b -> H a c; f # g = Fn (\k -> invoke f (g # k)) > :t ( # ) ( # ) :: H b c -> H a b -> H a c }}} Interestingly writing it in terms of `fix` does not type check with the more general type {{{ > import Data.Function > :t fix $ \self -> \f g -> Fn (\k -> invoke f (self g k)) fix $ \self -> \f g -> Fn (\k -> invoke f (self g k)) :: H a a -> H a a -> H a a > :t (fix $ \self -> \f g -> Fn (\k -> invoke f (self g k))) :: H b c -> H a b -> H a c :1:2: error: • Couldn't match type ‘b1’ with ‘a1’ ‘b1’ is a rigid type variable bound by an expression type signature: forall b1 c1 a1. H b1 c1 -> H a1 b1 -> H a1 c1 at :1:60-82 ‘a1’ is a rigid type variable bound by an expression type signature: forall b1 c1 a1. H b1 c1 -> H a1 b1 -> H a1 c1 at :1:60-82 Expected type: H b1 c1 -> H a1 b1 -> H a1 c1 Actual type: H a1 a1 -> H a1 a1 -> H a1 a1 • In the expression: (fix $ \ self -> \ f g -> Fn (\ k -> ...)) :: H b c -> H a b -> H a c }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 15:09:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 15:09:06 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): * Attachment "stgVarsSizeRatio.png" removed. Free variables / other STG ratio -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 15:09:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 15:09:06 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.51b87c5358719828e9db2944bd15a476@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): * Attachment "stgVarsSizeRatio.png" added. Free variables / other STG ratio -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 16:10:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 16:10:52 -0000 Subject: [GHC] #14426: Inferred type not principle/most general? In-Reply-To: <051.592e64f83e53fe7f919c84659111f8d5@haskell.org> References: <051.592e64f83e53fe7f919c84659111f8d5@haskell.org> Message-ID: <066.72ee511520bb85b9e0a2b4716192d4ae@haskell.org> #14426: Inferred type not principle/most general? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 RyanGlScott): * status: new => closed * resolution: => invalid Comment: This is expected behavior. The issue is that the `Fn` constructor uses polymorphic recursion, and type inference in the presence of polymorphic recursion is known to be undecidable. You managed to get lucky and have GHC infer any type at all for `(#)`, but often type inference will fail completely in the presence of polymorphic recursion, as in the example below: {{{#!hs data FullTree a = Leaf | Bin a (FullTree (a, a)) -- size :: FullTree a -> Int size Leaf = 0 size (Bin _ t) = 1 + 2 * size t }}} See the [https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-810004.4.1 Haskell Report's section on type signatures] for more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 16:17:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 16:17:50 -0000 Subject: [GHC] #13824: ghc 8.2 does not build for me on ppc64le In-Reply-To: <048.696afd9b4d70bfaf30354dc33faf7c20@haskell.org> References: <048.696afd9b4d70bfaf30354dc33faf7c20@haskell.org> Message-ID: <063.b28e39ca99754866371aa085d8e4c264@haskell.org> #13824: ghc 8.2 does not build for me on ppc64le ----------------------------------------+--------------------------------- Reporter: msuchanek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+--------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 16:45:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 16:45:50 -0000 Subject: [GHC] #14426: Inferred type not principle/most general? In-Reply-To: <051.592e64f83e53fe7f919c84659111f8d5@haskell.org> References: <051.592e64f83e53fe7f919c84659111f8d5@haskell.org> Message-ID: <066.b7f9d765811b3ebdfcaa9698072939c6@haskell.org> #14426: Inferred type not principle/most general? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Ah polymorphic recursion, that's right. Thanks Ryan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 16:51:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 16:51:06 -0000 Subject: [GHC] #14424: lcm :: Word -> Word -> Word is not specialised In-Reply-To: <047.63414eee7322738e08b3c70ef95b2d25@haskell.org> References: <047.63414eee7322738e08b3c70ef95b2d25@haskell.org> Message-ID: <062.1246ca740068af0006588989c9859e19@haskell.org> #14424: lcm :: Word -> Word -> Word is not specialised -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by Bodigrim): Should I prepare a pull request? Will GitHub do? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 17:05:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 17:05:33 -0000 Subject: [GHC] #14427: GHCi output change breaks tooling users Message-ID: <046.9530f469625f9852b11e9932b67ea56e@haskell.org> #14427: GHCi output change breaks tooling users -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: GHCi | Version: 8.2.1 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 Phab:D3651 we changed the output produced by GHCi when loading a module. Unfortunately this broke `haskell-mode`, which relies on this output. Upstream tickets: * https://github.com/haskell/haskell-mode/issues/1553 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 17:05:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 17:05:42 -0000 Subject: [GHC] #14427: GHCi output change breaks tooling users In-Reply-To: <046.9530f469625f9852b11e9932b67ea56e@haskell.org> References: <046.9530f469625f9852b11e9932b67ea56e@haskell.org> Message-ID: <061.dad96bd08d95b409451cf1355930b97c@haskell.org> #14427: GHCi output change breaks tooling users -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: GHCi | Version: 8.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): Phab:D1464 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D1464 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 17:06:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 17:06:05 -0000 Subject: [GHC] #14427: GHCi output change breaks tooling users In-Reply-To: <046.9530f469625f9852b11e9932b67ea56e@haskell.org> References: <046.9530f469625f9852b11e9932b67ea56e@haskell.org> Message-ID: <061.6e997e9acc8160fd866905bbc73f0737@haskell.org> #14427: GHCi output change breaks tooling users -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: GHCi | Version: 8.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): Phab:D4164 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D1464 => Phab:D4164 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 17:08:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 17:08:51 -0000 Subject: [GHC] #14428: Rework HsValBindsLR Message-ID: <044.498eb271c3cdcf7558aabf64c1af3410@haskell.org> #14428: Rework HsValBindsLR -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Once Trees that Grow has been applied to the hsSyn AST, rework `HsValBindsLR` to simplify it. From a comment on https://phabricator.haskell.org/D4147 > Nothing here gives any clue that this is intended for the output of the renamer. And typechecker I think. > Plus I wonder if we'd be better served by {{{#!hs data HsValBindsLR idL idR = ValBinds [(RecFlag, LHsBindsLR idL idR)] [LSig GhcRn] }}} > Then the parser can generate a giant singleton Rec and the renamer can sort it out. Less fuss. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 17:09:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 17:09:08 -0000 Subject: [GHC] #14428: Rework HsValBindsLR In-Reply-To: <044.498eb271c3cdcf7558aabf64c1af3410@haskell.org> References: <044.498eb271c3cdcf7558aabf64c1af3410@haskell.org> Message-ID: <059.df7cfbd9a46c2eaffda3c236e925c086@haskell.org> #14428: Rework HsValBindsLR -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 alanz): * owner: (none) => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 17:22:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 17:22:46 -0000 Subject: [GHC] #14428: Rework HsValBindsLR In-Reply-To: <044.498eb271c3cdcf7558aabf64c1af3410@haskell.org> References: <044.498eb271c3cdcf7558aabf64c1af3410@haskell.org> Message-ID: <059.f9810e060dd7f2874439f54ebe2a86c5@haskell.org> #14428: Rework HsValBindsLR -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Shayan-Najd): * cc: sh.najd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 17:54:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 17:54:27 -0000 Subject: [GHC] #14424: lcm :: Word -> Word -> Word is not specialised In-Reply-To: <047.63414eee7322738e08b3c70ef95b2d25@haskell.org> References: <047.63414eee7322738e08b3c70ef95b2d25@haskell.org> Message-ID: <062.4a607f313e75961489219c79a995fd8a@haskell.org> #14424: lcm :: Word -> Word -> Word is not specialised -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:4 Bodigrim]: > Should I prepare a pull request? Absolutely! > Will GitHub do? Given that this should be a relatively small patch (perhaps as short as one line), I think a GitHub patch would suffice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 19:01:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 19:01:12 -0000 Subject: [GHC] #14429: Remove constraint types from HsExtension, post TTG Message-ID: <044.8d19340ede159162269fe3cf2f9aa150@haskell.org> #14429: Remove constraint types from HsExtension, post TTG -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Once Trees that Grow is landed on the hsSyn AST, remove the constraint types from `HsExtension.hs` Hopefully `DataId`, `HasSourceText`, `OutputableX` etc can all go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 19:01:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 19:01:27 -0000 Subject: [GHC] #14429: Remove constraint types from HsExtension, post TTG In-Reply-To: <044.8d19340ede159162269fe3cf2f9aa150@haskell.org> References: <044.8d19340ede159162269fe3cf2f9aa150@haskell.org> Message-ID: <059.ff61aa6fdfc705067ac64179cd8a47f0@haskell.org> #14429: Remove constraint types from HsExtension, post TTG -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 alanz): * owner: (none) => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 19:08:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 19:08:59 -0000 Subject: [GHC] #14430: lintUnfolding does not allow unfoldings to jump to enclosing join points Message-ID: <046.6216ada2e885c6002a71b2409ce20404@haskell.org> #14430: lintUnfolding does not allow unfoldings to jump to enclosing join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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 not sure why this does not show up in HEAD but it does show up in my loopification branch. It does look like a bug in GHC to me. With loopification, I get the following code in the interface of `Foreign.C.String`: {{{ d5fd65f7834390bebd0e80edc7b8f627 withCAStringLen1 :: String -> (CStringLen -> IO a) -> State# RealWorld -> (# State# RealWorld, a #) {- Arity: 3, HasNoCafRefs, Strictness: , Unfolding: (\ @ a (str :: String) (f :: CStringLen -> IO a) (eta :: State# RealWorld) -> case lenAcc @ Char str newCAString2 of wild { I# x -> case newAlignedPinnedByteArray# @ RealWorld x 1# eta of ds2 { (#,#) ipv ipv1 -> case unsafeFreezeByteArray# @ RealWorld ipv1 ipv of ds3 { (#,#) ipv2 ipv3 -> let { ptr :: Addr# = byteArrayContents# ipv3 } in let { $j :: State# RealWorld -> () -> (# State# RealWorld, a #) {- Arity: 2, Strictness: , Inline: [0], Unfolding: InlineRule (2, True, False) (\ (w :: State# RealWorld) (w1 :: ()) -> case (f (Ptr @ CChar ptr, wild)) `cast` (N:IO[0] _R) w of ds4 { (#,#) ipv4 ipv5 -> case touch# @ 'UnliftedRep @ ByteArray# ipv3 ipv4 of s4 { DEFAULT -> (# s4, ipv5 #) } }) -} = \ (w :: State# RealWorld)[OneShot] (w1 :: ())[OneShot] -> case (f (Ptr @ CChar ptr, wild)) `cast` (N:IO[0] _R) w of ds4 { (#,#) ipv4 ipv5 -> case touch# @ 'UnliftedRep @ ByteArray# ipv3 ipv4 of s4 { DEFAULT -> (# s4, ipv5 #) } } } in let { go :: [Char] -> Int -> State# RealWorld -> (# State# RealWorld, a #) {- Arity: 3, Strictness: , Inline: [~], Unfolding: InlineRule (3, True, False) (\ (ds :: [Char])[OneShot] (n :: Int)[OneShot] (eta1 :: State# RealWorld)[OneShot] -> letrec { go :: [Char] -> Int -> State# RealWorld -> (# State# RealWorld, a #) {- Arity: 3 -} = \ (ds1 :: [Char]) (n1 :: Int) (eta2 :: State# RealWorld) -> case ds1 of wild1 { [] -> case n1 of n2 { I# ipv4 -> $j eta2 () } : c cs -> case n1 of wild2 { I# i -> case c of wild3 { C# c# -> case writeInt8OffAddr# @ RealWorld ptr i (narrow8Int# (ord# c#)) eta2 of s2 { DEFAULT -> go cs (I# (+# i 1#)) s2 } } } } } in go ds n eta1) -} = \ (ds :: [Char])[OneShot] (n :: Int)[OneShot] (eta1 :: State# RealWorld)[OneShot] -> case n of ww { I# ww1 -> let { exit :: State# RealWorld -> (# State# RealWorld, a #) {- Arity: 1, Strictness: -} = \ (w :: State# RealWorld)[OneShot] -> case (f (Ptr @ CChar ptr, wild)) `cast` (N:IO[0] _R) w of ds4 { (#,#) ipv4 ipv5 -> case touch# @ 'UnliftedRep @ ByteArray# ipv3 ipv4 of s4 { DEFAULT -> (# s4, ipv5 #) } } } in letrec { $wgo :: [Char] -> Int# -> State# RealWorld -> (# State# RealWorld, a #) {- Arity: 3, Strictness: , Inline: [0] -} = \ (w :: [Char]) (ww2 :: Int#) (w1 :: State# RealWorld) -> case w of wild1 { [] -> exit w1 : c cs -> case c of wild2 { C# c# -> case writeInt8OffAddr# @ RealWorld ptr ww2 (narrow8Int# (ord# c#)) w1 of s2 { DEFAULT -> $wgo cs (+# ww2 1#) s2 } } } } in $wgo ds ww1 eta1 } } in go str newCAString2 ipv2 } } }) -} }}} Note how `go` references `j` not only in its RHS, but also in its unfolding. When loading this interface, I get this error: {{{ HC [stage 1] libraries/base/dist-install/build/System/Posix/Internals.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20171101 for x86_64-unknown-linux): Iface Lint failure In interface for Foreign.C.String Unfolding of go_a6h7 : warning: In the expression: jump $j_a6gX eta2_a6hS () Invalid occurrence of a join variable: $j_a6gX The binder is either not a join point, or not valid here go_a6h7 = \ (ds_a6hM [OS=OneShot] :: [Char]) (n_a6hN [OS=OneShot] :: Int) (eta1_a6hO [OS=OneShot] :: State# RealWorld) -> joinrec { go_a6hP :: [Char] -> Int -> State# RealWorld -> (# State# RealWorld, a_a6gD #) [LclId[JoinId(3)], Arity=3] go_a6hP (ds1_a6hQ :: [Char]) (n1_a6hR :: Int) (eta2_a6hS :: State# RealWorld) = case ds1_a6hQ of wild1_a6hT { [] -> case n1_a6hR of n2_a6hW { I# ipv4_a6hY -> jump $j_a6gX eta2_a6hS () }; : c_a6i1 cs_a6i2 -> case n1_a6hR of wild2_a6i4 { I# i_a6i6 -> case c_a6i1 of wild3_a6i8 { C# c#_a6ia -> case writeInt8OffAddr# @ RealWorld ptr_a6gT i_a6i6 (narrow8Int# (ord# c#_a6ia)) eta2_a6hS of s2_a6ic { __DEFAULT -> jump go_a6hP cs_a6i2 (I# (+# i_a6i6 1#)) s2_a6ic } } } }; } in jump go_a6hP ds_a6hM n_a6hN eta1_a6hO Iface expr = \ (ds :: [Char])[OneShot] (n :: Int)[OneShot] (eta1 :: State# RealWorld)[OneShot] -> letrec { go :: [Char] -> Int -> State# RealWorld -> (# State# RealWorld, a #) {- Arity: 3 -} = \ (ds1 :: [Char]) (n1 :: Int) (eta2 :: State# RealWorld) -> case ds1 of wild1 { [] -> case n1 of n2 { I# ipv4 -> $j eta2 () } : c cs -> case n1 of wild2 { I# i -> case c of wild3 { C# c# -> case writeInt8OffAddr# @ RealWorld ptr i (narrow8Int# (ord# c#)) eta2 of s2 { DEFAULT -> go cs (I# (+# i 1#)) s2 } } } } } in go ds n eta1 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1147:37 in ghc:Outputable pprPanic, called at compiler/iface/TcIface.hs:1664:33 in ghc:TcIface }}} When reading the code in `tcPragExpr` I see that it lints the unfolding of `go` using `lintUnfolding`, which initializes the `LintM` with an empty `le_joins`. But when linting `go`, the join `j` is valid, even in the unfolding, isn't it? Unless of course I just don’t see the problem with the above unfolding, and am barking up the wrong tree. Anyways, either there is a problem in how we lint the unfoldings, or there is a secret invariant that I violated with my patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 19:10:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 19:10:17 -0000 Subject: [GHC] #14429: Remove constraint types from HsExtension, post TTG In-Reply-To: <044.8d19340ede159162269fe3cf2f9aa150@haskell.org> References: <044.8d19340ede159162269fe3cf2f9aa150@haskell.org> Message-ID: <059.2360242e6d11873aaa4f8f684efd3d49@haskell.org> #14429: Remove constraint types from HsExtension, post TTG -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 alanz): This should also allow the type family declarations for the extension points to move back to their natural place in the hsSyn directory, with the data type they are extending. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 19:56:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 19:56:44 -0000 Subject: [GHC] #14425: approxRational is wrong when (rat - eps) overflows in negative direction In-Reply-To: <046.eb71da6200dae7e365172a0968ad4790@haskell.org> References: <046.eb71da6200dae7e365172a0968ad4790@haskell.org> Message-ID: <061.bc4f7989858589be1379a7f167ecb057@haskell.org> #14425: approxRational is wrong when (rat - eps) overflows in negative direction -------------------------------------+------------------------------------- Reporter: danielk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: T14425 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4168 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => T14425 * status: new => patch * differential: => Phab:D4168 * milestone: => 8.4.1 Comment: See Phab:D4168. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 20:03:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 20:03:59 -0000 Subject: [GHC] #5889: -fno-prof-count-entries leads to linking errors In-Reply-To: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> References: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> Message-ID: <058.b0de6d347929f42d12ff70597f74b7c8@haskell.org> #5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > At the risk of stating the obvious, because the tick is around a `Case`, not a `Var`. Well, I think simonpj's question was really "why is the same simplification not also being performed when we inline the unfolding?" Indeed this is a good question and will need some investigation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 20:15:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 20:15:46 -0000 Subject: [GHC] #14414: Profiled program runs 2.5x faster than non-profiled In-Reply-To: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> References: <047.8a9712c347a66247e2c1df1268e2e56c@haskell.org> Message-ID: <062.18203418b4c9f170db499b68c0fc3d92@haskell.org> #14414: Profiled program runs 2.5x faster than non-profiled -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): Indeed the spinning explanation sounds quite plausible to me. In addition to the suggestions made by duog, you might also consider trying with `-fno-omit-yields`, which ensures that even non-allocating code segments perform an occasional heap check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 20:30:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 20:30:56 -0000 Subject: [GHC] #14431: Peculiar RTS crash on OS X Message-ID: <046.50af1b780509b4198d8903bef0dbcaf2@haskell.org> #14431: Peculiar RTS crash on OS X ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: ----------------------------------------+--------------------------------- This [[https://phabricator.haskell.org/harbormaster/build/36804/|Harbormaster build]] failed with an odd RTS crash from the stage0 compiler (which is 8.2.1), {{{ ghc: internal error: RELEASE_LOCK: I do not own this lock: rts/posix/itimer/Pthread.c 187 (GHC version 8.2.1 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It's not immediately clear to me from the implementation how this could happen, but I thought I should at least note the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 21:39:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 21:39:33 -0000 Subject: [GHC] #14415: Win32 SEH unwinding should print segfaults to stderr, not stdout In-Reply-To: <051.c9a792f5c8906425b56d08077a9b1ab2@haskell.org> References: <051.c9a792f5c8906425b56d08077a9b1ab2@haskell.org> Message-ID: <066.9e85c1920d777a4b7c45beeea6719506@haskell.org> #14415: Win32 SEH unwinding should print segfaults to stderr, not stdout -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4151 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4dfb790ca0611d4024cd01ba4c28d145f1deb7cb/ghc" 4dfb790/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4dfb790ca0611d4024cd01ba4c28d145f1deb7cb" rts/win32: Emit exception handler output to stderr Test Plan: Validate Reviewers: Phyx, austin, erikd, simonmar Reviewed By: Phyx Subscribers: rwbarton, thomie GHC Trac Issues: #14415 Differential Revision: https://phabricator.haskell.org/D4151 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 21:39:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 21:39:34 -0000 Subject: [GHC] #14361: GHC HEAD miscompiles `text-containers` In-Reply-To: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> References: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> Message-ID: <057.80d74dd1bff2361de4205cf47e3bdee4@haskell.org> #14361: GHC HEAD miscompiles `text-containers` -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a27056f9823f8bbe2302f1924b3ab38fd6752e37/ghc" a27056f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a27056f9823f8bbe2302f1924b3ab38fd6752e37" cmm/CBE: Fix a few more zip uses Ensure that we don't consider lists of equal length to be equal when they are not. I noticed these while working on the fix for #14361. Reviewers: austin, simonmar, michalt Reviewed By: michalt Subscribers: rwbarton, thomie GHC Trac Issues: #14361 Differential Revision: https://phabricator.haskell.org/D4153 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 21:39:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 21:39:33 -0000 Subject: [GHC] #14361: GHC HEAD miscompiles `text-containers` In-Reply-To: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> References: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> Message-ID: <057.7a4f7207c73114cd06d33c53aef8e893@haskell.org> #14361: GHC HEAD miscompiles `text-containers` -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6f990c54f922beae80362fe62426beededc21290/ghc" 6f990c54/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6f990c54f922beae80362fe62426beededc21290" cmm/CBE: Fix comparison between blocks of different lengths Previously CBE computed equality by taking the lists of middle nodes of the blocks being compared and zipping them together. It would then map over this list with the equality relation, and accumulate the result. However, this is completely wrong: Consider what will happen when we compare a block with no middle nodes with one with one or more. The result of `zip` will be empty and consequently the pass may conclude that the two are indeed equivalent (if their last nodes also match). This is very bad and the cause of #14361. The solution I chose was just to write out an explicit recursion, like I distinctly recall considering doing when I first wrote this code. Unfortunately I was feeling clever at the time. Unfortunately this case was just rare enough not to be triggered by the testsuite. I still need to find a testcase that doesn't have external dependencies. Test Plan: Need to find a more minimal testcase Reviewers: austin, simonmar, michalt Reviewed By: michalt Subscribers: michalt, rwbarton, thomie, hvr GHC Trac Issues: #14361 Differential Revision: https://phabricator.haskell.org/D4152 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 21:39:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 21:39:34 -0000 Subject: [GHC] #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers In-Reply-To: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> References: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> Message-ID: <062.305db5a5787482f21c55276dc731d5a3@haskell.org> #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Prelude | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #12537 | Differential Rev(s): Phab:D4009 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"59de290928e6903337f31c1f8107ac8a98ea145d/ghc" 59de2909/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="59de290928e6903337f31c1f8107ac8a98ea145d" Update autoconf test for gcc to require 4.7 and up Fixing #14244 required the newer gcc atomic built-ins that are provided from 4.7 and up. This updates the test to check for minimum gcc version 4.7. The version tests for 3.4 (!), 4.4, and 4.6 are no longer needed and can be removed. This makes the build system simpler. Test Plan: validate Reviewers: austin, bgamari, hvr, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D4165 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 21:39:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 21:39:34 -0000 Subject: [GHC] #14427: GHCi output change breaks tooling users In-Reply-To: <046.9530f469625f9852b11e9932b67ea56e@haskell.org> References: <046.9530f469625f9852b11e9932b67ea56e@haskell.org> Message-ID: <061.d899adceabfaddfe74c4de46f66a8a6c@haskell.org> #14427: GHCi output change breaks tooling users -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: GHCi | Version: 8.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): Phab:D4164 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8613e61de62178e76cd0f8915bd1fbe9c200a039/ghc" 8613e61/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8613e61de62178e76cd0f8915bd1fbe9c200a039" DynFlags: Introduce -show-mods-loaded flag This flag reintroduces the verbose module name output produced by GHCi's :load command behind a new flag, -show-mods-loaded. This was originally removed in D3651 but apparently some tools (e.g. haskell-mode) rely on this output. Addresses #14427. Test Plan: Validate Reviewers: svenpanne Reviewed By: svenpanne Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4164 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 21:39:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 21:39:34 -0000 Subject: [GHC] #14424: lcm :: Word -> Word -> Word is not specialised In-Reply-To: <047.63414eee7322738e08b3c70ef95b2d25@haskell.org> References: <047.63414eee7322738e08b3c70ef95b2d25@haskell.org> Message-ID: <062.ca6e8057f5ae2d2c6f1f9b36d4934843@haskell.org> #14424: lcm :: Word -> Word -> Word is not specialised -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"66b5b3eef1aa9fa9f192a85847d34b2756bec33f/ghc" 66b5b3e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="66b5b3eef1aa9fa9f192a85847d34b2756bec33f" Specialise lcm :: Word -> Word -> Word (trac#14424) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 21:40:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 21:40:10 -0000 Subject: [GHC] #14424: lcm :: Word -> Word -> Word is not specialised In-Reply-To: <047.63414eee7322738e08b3c70ef95b2d25@haskell.org> References: <047.63414eee7322738e08b3c70ef95b2d25@haskell.org> Message-ID: <062.5fc7be9b999e1b748abeb1a8cc04c2a0@haskell.org> #14424: lcm :: Word -> Word -> Word is not specialised -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 Comment: Merged. Thanks Bodigrim! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 21:52:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 21:52:16 -0000 Subject: [GHC] #5889: -fno-prof-count-entries leads to linking errors In-Reply-To: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> References: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> Message-ID: <058.d20982768e6a98bd9e0641dff77b5883@haskell.org> #5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): Replying to [comment:15 bgamari]: > Well, I think simonpj's question was really "why is the same simplification not also being performed when we inline the unfolding?" Indeed this is a good question and will need some investigation. One explanation could be that `newTyConEtadRhs` is inlined at the callsite of `newTyConInstRhs` because the constructor of `tycon_a9Sq` is known; and after that substitution the logic in comment:9 no longer applies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 21:54:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 21:54:43 -0000 Subject: [GHC] #14427: GHCi output change breaks tooling users In-Reply-To: <046.9530f469625f9852b11e9932b67ea56e@haskell.org> References: <046.9530f469625f9852b11e9932b67ea56e@haskell.org> Message-ID: <061.b48c7c8c7186e9ff92015587d12da0f8@haskell.org> #14427: GHCi output change breaks tooling users -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: GHCi | Version: 8.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): Phab:D4164 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 21:55:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 21:55:41 -0000 Subject: [GHC] #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers In-Reply-To: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> References: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> Message-ID: <062.ab850757d3223a100244bbfdf9e916d4@haskell.org> #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Prelude | Version: 8.2.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: #12537 | Differential Rev(s): Phab:D4009 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 21:55:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 21:55:57 -0000 Subject: [GHC] #14361: GHC HEAD miscompiles `text-containers` In-Reply-To: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> References: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> Message-ID: <057.15444115a8c3993b0c21aa8a08927f17@haskell.org> #14361: GHC HEAD miscompiles `text-containers` -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 21:56:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 21:56:09 -0000 Subject: [GHC] #14415: Win32 SEH unwinding should print segfaults to stderr, not stdout In-Reply-To: <051.c9a792f5c8906425b56d08077a9b1ab2@haskell.org> References: <051.c9a792f5c8906425b56d08077a9b1ab2@haskell.org> Message-ID: <066.0d81a6b1edf33681a69fcdc5f9feca8d@haskell.org> #14415: Win32 SEH unwinding should print segfaults to stderr, not stdout -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4151 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 21:58:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 21:58:48 -0000 Subject: [GHC] #14339: GHC 8.2.1 regression when combining GND with TypeError (solveDerivEqns: probable loop) In-Reply-To: <050.71c0075dc8f8df8e6578520d1b23a3ca@haskell.org> References: <050.71c0075dc8f8df8e6578520d1b23a3ca@haskell.org> Message-ID: <065.abfd1b85dd0462fe5ec29487057ccf15@haskell.org> #14339: GHC 8.2.1 regression when combining GND with TypeError (solveDerivEqns: probable loop) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: deriving, Resolution: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | testsuite/tests/deriving/should_compile/T14339 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.3 => 8.2.2 Comment: Ahh, good catch RyanGlScott. Actually I think we can sneak it in to 8.2.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 6 23:53:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Nov 2017 23:53:37 -0000 Subject: [GHC] #14432: Outdated comment in GHC.Real Message-ID: <047.5338823393ca6b66c7faac41f6269e57@haskell.org> #14432: Outdated comment in GHC.Real -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 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: -------------------------------------+------------------------------------- `GHC.Real` (lines 518-534) says: {{{ {- Rules for powers with known small exponent ... It might be desirable to have corresponding rules also for exponents of other types, in particular Word, but we can't have those rules here (importing GHC.Word or GHC.Int would create a cyclic module dependency), and it's doubtful they would fire, since the exponents of other types tend to get floated out before the rule has a chance to fire. }}} The remark about cyclic module dependency seems to be outdated: nowadays `GHC.Real` certainly has `Word` in scope. My proposal is to exclude this remark and change the paragraph to {{{ It might be desirable to have corresponding rules also for exponents of other types (e. g., Word), but it's doubtful they would fire, since the exponents of other types tend to get floated out before the rule has a chance to fire. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 01:48:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 01:48:01 -0000 Subject: [GHC] #14331: Overzealous free-floating kind check causes deriving clause to be rejected In-Reply-To: <050.cb87f2a10e38fd0ac57d92b074ac5d5b@haskell.org> References: <050.cb87f2a10e38fd0ac57d92b074ac5d5b@haskell.org> Message-ID: <065.04d2fbd6e466be7c2e9426f11c2d069b@haskell.org> #14331: Overzealous free-floating kind check causes deriving clause to be rejected -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14331 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Most of the arcane knowledge is just knowledge of Haskell. The rest is but a small epsilon... :) There are basically two families of zonking functions: 1. The functions defined in `TcMType` do an intermediate zonk. They squeeze out filled-in metavariables but don't run into trouble (or do anything, really) if they encounter an unfilled metavariable. The most frequently called function from this family is `zonkTcType`. These functions are needed during type-checking when, say, we are about to look at the free variables of something. Doing that without zonking first might give wrong information. 2. The functions defined in `TcHsSyn` (such as `zonkTcTypeToType`) do a final zonk. If one of these functions encounters a metavariable, that metavariable is zonked to `Any` (most of the time -- details unimportant at the moment). This zonking happens when desugaring the type-checked program into Core; it also happens when building tycons from user-written type declarations. The basic idea is that we would like to consider `TcType` and `Type` as two separate types; the former lives in the type-checker and the latter lives in Core. `zonkTcType` both takes and returns a `TcType`. `zonkTcTypeToType` takes a `TcType` and returns a `Type`. As for `zonkQuantifiedTyVar`: that does more than just zonk -- it also skolemizes. (That is, it takes an unfilled metavariable and turns it into a skolem, which is useful when you're about to generalize.) Contrast with `zonkTyBndrX` (part of the final zonk), which ''expects'' a skolem to begin with. I remember it took years before I finally grokked zonking. And now I can't tell you why it seemed so hard! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 01:54:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 01:54:29 -0000 Subject: [GHC] #14420: Data families should not instantiate to non-Type kinds In-Reply-To: <047.a64d114cfae11861b31f70375118e394@haskell.org> References: <047.a64d114cfae11861b31f70375118e394@haskell.org> Message-ID: <062.bee560f51ca538893035c70ba60518f6@haskell.org> #14420: Data families should not instantiate to non-Type kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: TypeInType => Comment: This is not related to `TypeInType`. I suppose I won't argue if you want to make a new keyword `RichardsBailiwick`, but this truly isn't `TypeInType`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 03:11:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 03:11:01 -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.d0af7301e335a826a8af6e6bdbcb8ffb@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I'm not saying that it's wrong for GHC to complain. Ed seems to be saying that he doesn't want GHC to consider this an error, because that breaks his `unsafeCoerce`ful code. It's up to you whether you find his argument compelling. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 03:13:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 03:13:55 -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.1d6c88f63e9d2d5cdf03dbfb5924a3a7@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): To put it a bit differently, I believe that whereas you write "`foo` cannot be called", Ed is effectively calling `foo (unsafeCoerce Refl)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 05:09:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 05:09:15 -0000 Subject: [GHC] #14433: Windows10 GHCI Crash, it can't run correctly Message-ID: <046.b6bae8d51e87c7b5229b5e0810340119@haskell.org> #14433: Windows10 GHCI Crash, it can't run correctly --------------------------------------+---------------------------------- Reporter: Shizumi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- I followed the Haskel Platform website download the version 8.2.1 and installed it sucessfully, i add the extra path too.But when I open GHCI in start menu or in PowerShell,it cant run sucessfully, below are the error message, ps: here is Windows 10 Pro Insider Preview, does it matter or what? PS C:\Users\SHIZU-NOTEBOOK\Desktop> ghci GHCI, version 8.2.1: http://www.haskell.org/ghc/ :? for help ghc.exe: internal error: mkPath failed converting char* to wchar_t* (GHC version 8.2.1 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. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 08:35:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 08:35:57 -0000 Subject: [GHC] #14420: Data families should not instantiate to non-Type kinds In-Reply-To: <047.a64d114cfae11861b31f70375118e394@haskell.org> References: <047.a64d114cfae11861b31f70375118e394@haskell.org> Message-ID: <062.3821124c9012da650f5c62b752a95951@haskell.org> #14420: Data families should not instantiate to non-Type kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: TypeFamilies 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): * keywords: => TypeFamilies Comment: OK. What keyword should we give it? Otherwise, with 14,000+ tickets, it just gets lost in the sea. Let's try `TypeFamilies`, [wiki:TypeFunctions summarised here] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 08:38:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 08:38:36 -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.234a6a07644ddf53b5a66e5448942840@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): But `foo (unsafeCoerce Refl)` asks GHC to come up with a proof of `1 :~: Gcd 3 4` and pass it as an implicit argument. Which it cannot do. (Remember this isn't the usual `Gcd`; it's a hypothetical nullary function.) So in fact I can't call `foo`. Rather than speculate about Ed let's see if he wants to say anything himself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 09:20:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 09:20:11 -0000 Subject: [GHC] #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance Message-ID: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We experienced code breakage while moving to 8.2.1 - in some circumstances it picks wrong instances if an instance in the lines of `instance {-# OVERLAPPABLE #-} C a ` is defined. @s9gf4ult was really nice to create a repo demonstrating an issue, you can look at the repo here: [https://github.com/s9gf4ult/isogen-minimal-example] Running `chech.sh` will trigger three builds: {{{ GHC 8.0.2, -O, succeeds GHC 8.2.1, -O0, succeeds GHC 8.2.1, -O, fails }}} If you'll check out to either of fix- branches: {{{ fix-move-to_string fix-no-catchall-instance fix-replace-to_string fix-add-irrelevant-instance }}} then the last test should succeed also. Those branches contain changes over master which fixes the bug in different ways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 11:09:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 11:09:27 -0000 Subject: [GHC] #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.82c8166d200372a2adcd36fc9876a4aa@haskell.org> #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context -------------------------------------+------------------------------------- Reporter: cactus | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:51 AntC]: > Pattern synonym used in an expression context could act as a smart constructor; and be used in a pattern context just for matching. > Ah, I see I can already do that. But that wasn't at all clear from the docos. So ignore comment:51, here's some notes to improve [https://downloads.haskell.org/~ghc/8.2.1/docs/html/users_guide/glasgow_exts.html #pattern-synonyms the User Guide] -- which mentions a wiki page, but I can't find that. Does it mean the implementation notes linked from comment:24? To make a smart constructor: {{{ data Dumb = Dumb Int pattern Smart { nonneg } <- Dumb nonneg where Smart nonneg = if nonneg >= 0 then (Dumb nonneg) else error "Smart constructor called on negative" }}} Things I noticed: * The User Guide syntax for explicit bidirectionals is not quite right: it says the lhs's are both `pat_lhs`, but you can only use Record syntax on the first line with `<-`; the second line with `=` must use Prefix or Infix. * You can put an arbitrary `expr` on rhs of the `=`. The User Guide says that, but gives no examples other than Data constructors. * On the rhs of `=`, the pattern/constructor doesn't have to be the same as on the `<-` line. Indeed you can go {{{ data PosNeg = Pos Int | Neg Int pattern Smarter{ nonneg } <- Pos nonneg where Smarter x = if x >= 0 then (Pos x) else (Neg x) }}} And I guess that possibility is why you can't use Record syntax on lhs of the `=`: you don't know which combo of field names applies until you know which data constructor you're producing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 14:15:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 14:15:51 -0000 Subject: [GHC] #14435: GHC 8.2.1 regression: -ddump-tc-trace hangs forever Message-ID: <050.f79763c959484930d3e3639e305f9f0b@haskell.org> #14435: GHC 8.2.1 regression: -ddump-tc-trace hangs forever -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | 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: -------------------------------------+------------------------------------- Thanks to Christiaan Baaij for noticing this. Take this program: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Type.Equality import GHC.TypeLits type family Replicate (n :: Nat) (x :: a) :: [a] where Replicate 0 _ = '[] Replicate n x = x : Replicate (n - 1) x replicateSucc :: (Replicate (k + 1) x) :~: (x : Replicate k x) replicateSucc = Refl }}} Note that this program does not typecheck (nor should it). In GHC 8.0.2 and 8.2.1, if you compile this with no tracing flags, it'll give the error: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:16:17: error: • Couldn't match type ‘Replicate (k + 1) x’ with ‘x : Replicate k x’ Expected type: Replicate (k + 1) x :~: (x : Replicate k x) Actual type: (x : Replicate k x) :~: (x : Replicate k x) • In the expression: Refl In an equation for ‘replicateSucc’: replicateSucc = Refl • Relevant bindings include replicateSucc :: Replicate (k + 1) x :~: (x : Replicate k x) (bound at Bug.hs:16:1) | 16 | replicateSucc = Refl | ^^^^ }}} Things become interesting when you compile this program with `-ddump-tc- trace`. In GHC 8.0.2, it'll trace some extra output and eventually reach the same error as above. In 8.2.1, however, the tracing hangs, causing compilation to never terminate! Here is the output right before it hangs: {{{ lk1 : tc_infer_args (invis) @a_11 tc_infer_args (vis) [anon] a_11 x_a1Dt lk1 x_a1Dt u_tys tclvl 1 k0_a1GD[tau:1] ~ a0_a1GF[tau:1] arising from a type equality k0_a1GD[tau:1] ~ a0_a1GF[tau:1] found filled tyvar k_a1GD[tau:1] :-> a0_a1GE[tau:1] u_tys tclvl 1 * ~ * arising from a kind equality arising from a0_a1GE[tau:1] ~ a0_a1GF[tau:1] u_tys tclvl 1 'GHC.Types.LiftedRep ~ 'GHC.Types.LiftedRep arising from a kind equality arising from a0_a1GE[tau:1] ~ a0_a1GF[tau:1] u_tys yields no coercion u_tys yields no coercion writeMetaTyVar a_a1GE[tau:1] :: * := a0_a1GF[tau:1] u_tys yields no coercion checkExpectedKind k0_a1GD[tau:1] a0_a1GF[tau:1] _N tc_infer_args (vis) [anon] [a_11] Replicate (n_a1Ds - 1) x_a1Dt lk1 Replicate instantiating tybinders: @a_a1Dp := a0_a1GG[tau:1] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 14:30:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 14:30:11 -0000 Subject: [GHC] #14435: GHC 8.2.1 regression: -ddump-tc-trace hangs forever In-Reply-To: <050.f79763c959484930d3e3639e305f9f0b@haskell.org> References: <050.f79763c959484930d3e3639e305f9f0b@haskell.org> Message-ID: <065.0e7c176f25f3f8eb19e6286960572ac7@haskell.org> #14435: GHC 8.2.1 regression: -ddump-tc-trace hangs forever -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | 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: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > Thanks to Christiaan Baaij for noticing this. Take this program: > > {{{#!hs > {-# LANGUAGE AllowAmbiguousTypes #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeInType #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} > module Bug where > > import Data.Type.Equality > import GHC.TypeLits > > type family Replicate (n :: Nat) (x :: a) :: [a] where > Replicate 0 _ = '[] > Replicate n x = x : Replicate (n - 1) x > > replicateSucc :: (Replicate (k + 1) x) :~: (x : Replicate k x) > replicateSucc = Refl > }}} > > Note that this program does not typecheck (nor should it). In GHC 8.0.2 > and 8.2.1, if you compile this with no tracing flags, it'll give the > error: > > {{{ > $ /opt/ghc/8.2.1/bin/ghci Bug.hs > GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/rgscott/.ghci > [1 of 1] Compiling Bug ( Bug.hs, interpreted ) > > Bug.hs:16:17: error: > • Couldn't match type ‘Replicate (k + 1) x’ > with ‘x : Replicate k x’ > Expected type: Replicate (k + 1) x :~: (x : Replicate k x) > Actual type: (x : Replicate k x) :~: (x : Replicate k x) > • In the expression: Refl > In an equation for ‘replicateSucc’: replicateSucc = Refl > • Relevant bindings include > replicateSucc :: Replicate (k + 1) x :~: (x : Replicate k x) > (bound at Bug.hs:16:1) > | > 16 | replicateSucc = Refl > | ^^^^ > }}} > > Things become interesting when you compile this program with `-ddump-tc- > trace`. In GHC 8.0.2, it'll trace some extra output and eventually reach > the same error as above. In 8.2.1, however, the tracing hangs, causing > compilation to never terminate! Here is the output right before it hangs: > > {{{ > lk1 : > tc_infer_args (invis) @a_11 > tc_infer_args (vis) > [anon] a_11 > x_a1Dt > lk1 x_a1Dt > u_tys > tclvl 1 > k0_a1GD[tau:1] ~ a0_a1GF[tau:1] > arising from a type equality k0_a1GD[tau:1] ~ a0_a1GF[tau:1] > found filled tyvar k_a1GD[tau:1] :-> a0_a1GE[tau:1] > u_tys > tclvl 1 > * ~ * > arising from a kind equality arising from > a0_a1GE[tau:1] ~ a0_a1GF[tau:1] > u_tys > tclvl 1 > 'GHC.Types.LiftedRep ~ 'GHC.Types.LiftedRep > arising from a kind equality arising from > a0_a1GE[tau:1] ~ a0_a1GF[tau:1] > u_tys yields no coercion > u_tys yields no coercion > writeMetaTyVar a_a1GE[tau:1] :: * := a0_a1GF[tau:1] > u_tys yields no coercion > checkExpectedKind > k0_a1GD[tau:1] > a0_a1GF[tau:1] > _N > tc_infer_args (vis) > [anon] [a_11] > Replicate (n_a1Ds - 1) x_a1Dt > lk1 Replicate > instantiating tybinders: @a_a1Dp := a0_a1GG[tau:1] > }}} New description: Thanks to Christiaan Baaij for noticing this. Take this program: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Type.Equality import GHC.TypeLits type family Replicate (n :: Nat) (x :: a) :: [a] where Replicate 0 _ = '[] Replicate n x = x : Replicate (n - 1) x replicateSucc :: (Replicate (k + 1) x) :~: (x : Replicate k x) replicateSucc = Refl }}} Note that this program does not typecheck (nor should it). In GHC 8.0.2 and 8.2.1, if you compile this with no tracing flags, it'll give the error: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:16:17: error: • Couldn't match type ‘Replicate (k + 1) x’ with ‘x : Replicate k x’ Expected type: Replicate (k + 1) x :~: (x : Replicate k x) Actual type: (x : Replicate k x) :~: (x : Replicate k x) • In the expression: Refl In an equation for ‘replicateSucc’: replicateSucc = Refl • Relevant bindings include replicateSucc :: Replicate (k + 1) x :~: (x : Replicate k x) (bound at Bug.hs:16:1) | 16 | replicateSucc = Refl | ^^^^ }}} Things become interesting when you compile this program with `-ddump-tc- trace`. In GHC 8.0.2, it'll trace some extra output and eventually reach the same error as above. In 8.2.1, however, the tracing hangs, causing compilation to never terminate! Here is the output right before it hangs: {{{ lk1 : tc_infer_args (invis) @a_11 tc_infer_args (vis) [anon] a_11 x_a1Dt lk1 x_a1Dt u_tys tclvl 1 k0_a1GD[tau:1] ~ a0_a1GF[tau:1] arising from a type equality k0_a1GD[tau:1] ~ a0_a1GF[tau:1] found filled tyvar k_a1GD[tau:1] :-> a0_a1GE[tau:1] u_tys tclvl 1 * ~ * arising from a kind equality arising from a0_a1GE[tau:1] ~ a0_a1GF[tau:1] u_tys tclvl 1 'GHC.Types.LiftedRep ~ 'GHC.Types.LiftedRep arising from a kind equality arising from a0_a1GE[tau:1] ~ a0_a1GF[tau:1] u_tys yields no coercion u_tys yields no coercion writeMetaTyVar a_a1GE[tau:1] :: * := a0_a1GF[tau:1] u_tys yields no coercion checkExpectedKind k0_a1GD[tau:1] a0_a1GF[tau:1] _N tc_infer_args (vis) [anon] [a_11] Replicate (n_a1Ds - 1) x_a1Dt lk1 Replicate instantiating tybinders: @a_a1Dp := a0_a1GG[tau:1] instantiateTyN }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 14:46:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 14:46:53 -0000 Subject: [GHC] #11295: Figure out what LLVM passes are fruitful In-Reply-To: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> References: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> Message-ID: <061.40bde39f4830e61c3b158fc4cc1beab6@haskell.org> #11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: kavon Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.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 bgamari): Any progress on a tuning for 8.4, Kavon? Thanks again for looking at this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 14:53:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 14:53:49 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.3d6c3dfa417d8295d19af610523ef41a@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): I've narrowed it down a bit more. This behaves nicely: {{{ module D where import Text.ParserCombinators.ReadP as ReadP import Control.Monad.State as State import Data.Char (ord) data DT = DT { field0 :: Int , field2 :: Int , field3 :: Int , field4 :: Int , field5 :: Int , field6 :: Int , field7 :: Int , field8 :: Int , field9 :: Int , field10 :: Int } getlD :: IO DT getlD = DT <$> (read <$> getLine) <*> (read <$> getLine) <*> (read <$> getLine) <*> (read <$> getLine) <*> (read <$> getLine) <*> (read <$> getLine) <*> (read <$> getLine) <*> (read <$> getLine) <*> (read <$> getLine) <*> (read <$> getLine) }}} But this doesn't: {{{ module D where import Text.ParserCombinators.ReadP as ReadP import Control.Monad.State as State import Data.Char (ord) data DT = DT { field0 :: Int , field2 :: Int , field3 :: Int , field4 :: Int , field5 :: Int , field6 :: Int , field7 :: Int , field8 :: Int , field9 :: Int , field10 :: Int } readD :: ReadP DT readD = DT <$> (ord <$> ReadP.get) <*> (ord <$> ReadP.get) <*> (ord <$> ReadP.get) <*> (ord <$> ReadP.get) <*> (ord <$> ReadP.get) <*> (ord <$> ReadP.get) <*> (ord <$> ReadP.get) <*> (ord <$> ReadP.get) <*> (ord <$> ReadP.get) <*> (ord <$> ReadP.get) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 14:56:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 14:56:01 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.d3717a693a932d03a97726d06ad6e574@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): * Attachment "t-10-dump.zip" added. Various GHC dumps for 10-field getline-appl and read-appl examples. Read misbehaves, getLine doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 15:19:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 15:19:26 -0000 Subject: [GHC] #14435: GHC 8.2.1 regression: -ddump-tc-trace hangs forever In-Reply-To: <050.f79763c959484930d3e3639e305f9f0b@haskell.org> References: <050.f79763c959484930d3e3639e305f9f0b@haskell.org> Message-ID: <065.6d672cd9537724528da073a8c705714f@haskell.org> #14435: GHC 8.2.1 regression: -ddump-tc-trace hangs forever -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: As it turns out, this has been fixed on GHC HEAD, by commit 791947db6db32ef7d4772a821a0823e558e3c05b (`Refactor tcInferApps.`), due to its removal of a call to `ppr ty` from a `traceTc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 15:57:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 15:57:22 -0000 Subject: [GHC] #14436: Teach TemplateHaskell to generate less eye-hurting names Message-ID: <046.678e6710dfe270273bc87bf5359ed125@haskell.org> #14436: Teach TemplateHaskell to generate less eye-hurting names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 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 you look at the Haddocks for, e.g., the `singletons` package, one sees dozens of signatures containing unsightly names containing long integers. For instance, in the equation list for `Data.Singletons.Prelude.Either.IsLeft` we have {{{ IsLeft (Left _z_6989586621679437436) = TrueSym0 IsLeft (Right _z_6989586621679437439) = FalseSym0 }}} For definitions with lots of variables things quickly become unreadable. These names appear this way because they are generated by TemplateHaskell's `newName` function. This name is ultimately converted to a GHC `System` name by `Convert.thRdrName`. Such `Name`s are then pretty- printed including their uniques (see `Name.pprSystem`). I'm not sure I see the rationale for this. Surely if the names are tidied properly (e.g. using `TyConRep.tidyType`) there should be no need for the unique suffix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 16:01:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 16:01:58 -0000 Subject: [GHC] #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance In-Reply-To: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> References: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> Message-ID: <064.64d653862753262f44c024111b3ded76@haskell.org> #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | 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): * priority: normal => high * milestone: => 8.2.3 Comment: Hmm, this looks pretty bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 16:05:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 16:05:50 -0000 Subject: [GHC] #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance In-Reply-To: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> References: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> Message-ID: <064.9595c803a699ccec3dbd54a8356b211d@haskell.org> #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | 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 simonpj): Don't worry -- I'm on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 16:51:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 16:51:14 -0000 Subject: [GHC] #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance In-Reply-To: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> References: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> Message-ID: <064.7cdd8c8626490fac527e37ad793cc394@haskell.org> #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dredozubov: Old description: > We experienced code breakage while moving to 8.2.1 - in some > circumstances it picks wrong instances if an instance in the lines of > `instance {-# OVERLAPPABLE #-} C a ` is defined. @s9gf4ult was really > nice to create a repo demonstrating an issue, you can look at the repo > here: [https://github.com/s9gf4ult/isogen-minimal-example] > > Running `chech.sh` will trigger three builds: > > {{{ > GHC 8.0.2, -O, succeeds > GHC 8.2.1, -O0, succeeds > GHC 8.2.1, -O, fails > }}} > > > If you'll check out to either of fix- branches: > > {{{ > fix-move-to_string > fix-no-catchall-instance > fix-replace-to_string > fix-add-irrelevant-instance > }}} > > then the last test should succeed also. Those branches contain changes > over master which fixes the bug in different ways. New description: We experienced code breakage while moving to 8.2.1 - in some circumstances it picks wrong instances if an instance in the lines of `instance {-# OVERLAPPABLE #-} C a ` is defined. @s9gf4ult was really nice to create a repo demonstrating an issue, you can look at the repo here: [https://github.com/s9gf4ult/isogen-minimal-example] Running `chech.sh` will trigger three builds: {{{ GHC 8.0.2, -O, succeeds GHC 8.2.1, -O0, succeeds GHC 8.2.1, -O, fails }}} If you'll check out to either of fix- branches: {{{ fix-move-to_string fix-no-catchall-instance fix-replace-to_string fix-add-irrelevant-instance }}} then the last test should succeed also. Those branches contain changes over master which fix the application behavior in different ways. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 16:55:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 16:55:09 -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.d980ef4e7ceb8f00eaef714d390c0619@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I'm not particularly wedded to whether I use {{{#!hs type family Gcd :: Nat -> Nat -> Nat }}} or {{{#!hs type family Gcd (n:: Nat) (m::Nat) :: Nat }}} here. The one thing I have in favor (or against, depending on your perspective) of the Nat -> Nat -> Nat encoding is that it allows me to preclude the user actually defining any ad hoc base cases. Switching to the other address the "eta" concern to some extent. The main usecase I have sort of mirrors this situation: In the module we're in Gcd 3 4 doesn't have a type instance, but that doesn't mean that in another context it might not be reducible. Say you define the type family in one module: {{{#!hs module Foo where type family Gcd (x :: Nat) (y :: Nat) :: Nat }}} but refine it later in another: {{{#!hs module Bar where type instance Gcd 3 4 = 1 }}} In Bar, we can perform the reduction, but in Foo we'd get stuck. The machinery in Data.Constraint.Nat acts much the same way. We later on get into a situation that lets us discharge a stuck constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 17:11:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 17:11:56 -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.39c14894df2dd8b1f385ec3cfd64738d@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): If what you're saying is that the fact that its `type family Gcd :: Nat -> Nat -> Nat`, rather than that other form, that is causing the problem, then I think I see where you're coming from. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 17:17:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 17:17: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.77b6cddd0fa1a9a10e007807e5c0081e@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > If what you're saying is that the fact that its type family Gcd :: Nat -> Nat -> Nat, rather than that other form, that is causing the problem Precisely. If `Gcd` is nullary, then `Gcd a b` can never be equal to `1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 17:38:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 17:38:01 -0000 Subject: [GHC] #14433: Windows10 GHCI Crash, it can't run correctly In-Reply-To: <046.b6bae8d51e87c7b5229b5e0810340119@haskell.org> References: <046.b6bae8d51e87c7b5229b5e0810340119@haskell.org> Message-ID: <061.76dc7febaa929ad91b7fa7eefe68aea3@haskell.org> #14433: Windows10 GHCI Crash, it can't run correctly ----------------------------------+-------------------------------------- Reporter: Shizumi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by bgamari): * cc: Phyx- (added) * milestone: => 8.4.1 Old description: > I followed the Haskel Platform website download the version 8.2.1 and > installed it sucessfully, i add the extra path too.But when I open GHCI > in start menu or in PowerShell,it cant run sucessfully, below are the > error message, ps: here is Windows 10 Pro Insider Preview, does it matter > or what? > > PS C:\Users\SHIZU-NOTEBOOK\Desktop> ghci > GHCI, version 8.2.1: http://www.haskell.org/ghc/ :? for help > ghc.exe: internal error: mkPath failed converting char* to wchar_t* > (GHC version 8.2.1 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. New description: I followed the Haskel Platform website download the version 8.2.1 and installed it sucessfully, i add the extra path too.But when I open GHCI in start menu or in PowerShell,it cant run sucessfully, below are the error message, ps: here is Windows 10 Pro Insider Preview, does it matter or what? {{{ PS C:\Users\SHIZU-NOTEBOOK\Desktop> ghci GHCI, version 8.2.1: http://www.haskell.org/ghc/ :? for help ghc.exe: internal error: mkPath failed converting char* to wchar_t* (GHC version 8.2.1 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. }}} -- Comment: Any idea what is going on here, Tamar? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 18:13:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 18:13:33 -0000 Subject: [GHC] #14396: Hs-boot woes during family instance consistency checks In-Reply-To: <046.2ccc4fa31be03dddd3503a257243a5e2@haskell.org> References: <046.2ccc4fa31be03dddd3503a257243a5e2@haskell.org> Message-ID: <061.85bd27f853273546780e5aea23e0d3f0@haskell.org> #14396: Hs-boot woes during family instance consistency checks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4154 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"93b4820607aed1ab633e836084c5e39f5e631f87/ghc" 93b4820/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="93b4820607aed1ab633e836084c5e39f5e631f87" Revert "WIP on combining Step 1 and 3 of Trees That Grow" This reverts commit 0ff152c9e633accca48815e26e59d1af1fe44ceb. Sadly this broke when bootstrapping with 8.0.2 due to #14396. Reverts haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 18:19:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 18:19:40 -0000 Subject: [GHC] #11392: Decide and document how semicolons are supposed to work in GHCi In-Reply-To: <046.d75fcf3d7505bd227ba71ab98306e831@haskell.org> References: <046.d75fcf3d7505bd227ba71ab98306e831@haskell.org> Message-ID: <061.9e63c7049e81333e3fcf9a48ed40ecdd@haskell.org> #11392: Decide and document how semicolons are supposed to work in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10663, #7625 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jkiefer): This looks interesting, but it seems to mostly already be resolved. With #10663, GHCi simply rejects multiple imports separated by semicolons. I'm not sure when this got fixed, but testing with GHCi 8.0.2 the parser state issue seems to have been fixed: {{{ λ> data Infix a b = a :@: b; infixl 7 :@: λ> a :2:1: error: Variable not in scope: a }}} Is there any more to be done? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 18:36:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 18:36:55 -0000 Subject: [GHC] #14436: Teach TemplateHaskell to generate less eye-hurting names In-Reply-To: <046.678e6710dfe270273bc87bf5359ed125@haskell.org> References: <046.678e6710dfe270273bc87bf5359ed125@haskell.org> Message-ID: <061.a4ecc0ad0ea3697b5d7ec425e505ee01@haskell.org> #14436: Teach TemplateHaskell to generate less eye-hurting names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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 goldfire): This may be unique to `singletons`. See [https://github.com/goldfirere/th- desugar/blob/master/Language/Haskell/TH/Desugar/Util.hs#L46 `newUniqueName`], which uses `newName`, `show`s it, and then uses the result to make ''another'' `newName`. This is necessary because these `newName`d entities are sometimes top-level, and GHC doesn't like two top- level entities to have the same `OccName`. I suppose this is really a workaround for an unreported GHC bug, but I don't think the bug is the one this ticket is really worried about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 18:40:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 18:40:43 -0000 Subject: [GHC] #14391: Make the simplifier independent of the typechecker In-Reply-To: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> References: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> Message-ID: <061.48995f3fd9271690a312e482b2416a42@haskell.org> #14391: Make the simplifier independent of the typechecker -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jkiefer): Hello. Am newcomer. I'd love to take a stab at this! Will start hacking away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 18:44:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 18:44:03 -0000 Subject: [GHC] #14437: Optimise remainders by powers of two Message-ID: <047.291113040ac7c3813fee479e4d1a965e@haskell.org> #14437: Optimise remainders by powers of two -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Current GHC optimises quotients, but not remainders by powers of two. For instance, even `even :: Word -> Bool` requires division: {{{#!hs evenWord :: Word -> Bool evenWord = even }}} results in CMM, containing {{{#!c if (I64[R1 + 7] % 2 != 0) goto c2sK; else goto c2sQ; }}} My proposal is to optimise `MO_{S,U}_Rem` by powers of two in `CmmOpt.cmmMachOpFoldM`, similar to existing cases for `MO_{S,U}_Quot`. Something like this may do: {{{#!hs MO_U_Rem rep | Just _ <- exactLog2 n -> Just (cmmMachOpFold dflags (MO_And rep) [x, CmmLit (CmmInt (n - 1) rep)]) MO_S_Rem rep | Just p <- exactLog2 n -> Just (cmmMachOpFold dflags (MO_Sub rep) [x, cmmMachOpFold dflags (MO_Shl rep) [cmmMachOpFold dflags (MO_S_Quot rep) [x, y], CmmLit (CmmInt p rep)]]) }}} Function `even` is used by default definition of `stimes` (`Data.Semigroup.Internal.stimesDefault`). If `<>` is cheap, division may become a bottleneck. It is also used by `GHC.Real.^`. Here is a simple benchmark: {{{#!hs v :: Int v = maximum [ x ^ (6 :: Word) | x <- [1..100000000 :: Int] ] }}} It takes 4.5 seconds on my PC before the patch above (`-O2`) and only 2.2 seconds after. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 19:40:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 19:40:00 -0000 Subject: [GHC] #14391: Make the simplifier independent of the typechecker In-Reply-To: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> References: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> Message-ID: <061.d6964a0cbe319e1ee20311666a6d17dc@haskell.org> #14391: Make the simplifier independent of the typechecker -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Great! Do let us know if you encounter trouble. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 19:42:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 19:42:29 -0000 Subject: [GHC] #14436: Teach TemplateHaskell to generate less eye-hurting names In-Reply-To: <046.678e6710dfe270273bc87bf5359ed125@haskell.org> References: <046.678e6710dfe270273bc87bf5359ed125@haskell.org> Message-ID: <061.da2b848a67d1f57a56bcd238d8ad1c0a@haskell.org> #14436: Teach TemplateHaskell to generate less eye-hurting names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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 bgamari): * status: new => closed * resolution: => invalid Comment: Ahh, then perhaps my analysis is faulty. Let's forget this happened then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 20:22:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 20:22:05 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2314438=3A_Using_a_=28meaningless=29_generi?= =?utf-8?q?c_currency_sign_=28=C2=A4=29_instead_of_=24_causes_pan?= =?utf-8?q?icing?= Message-ID: <045.ca9f499c59ecff2bf0fd2b9591b2a709@haskell.org> #14438: Using a (meaningless) generic currency sign (¤) instead of $ causes panicing --------------------------------------+--------------------------------- Reporter: Izmaki | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.0.2 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: --------------------------------------+--------------------------------- The following two lines of HS produces the reported error. It was actually a mistype and probably not that serious, but I was told to report it. The issue is combining the "generic currency" symbol ¤ with the Integral constraint (using e.g. Integer instead as the constraint does not produce the same error). {{{#!hs Prelude> let ones x = snd $ divMod x 10 Prelude> ones ¤ (5 :: Integral) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] ¤_a2l9 :: t_a2l8[tau:1] (CHoleCan: ¤) [W] ¤_a2lJ :: t_a2lI[tau:1] (CHoleCan: ¤)} 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 Tue Nov 7 21:06:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 21:06:24 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314438=3A_Using_a_=28meaningless=29_?= =?utf-8?q?generic_currency_sign_=28=C2=A4=29_instead_of_=24_caus?= =?utf-8?q?es_panicing?= In-Reply-To: <045.ca9f499c59ecff2bf0fd2b9591b2a709@haskell.org> References: <045.ca9f499c59ecff2bf0fd2b9591b2a709@haskell.org> Message-ID: <060.dcab2c714ae11cae3a359259c19d0c00@haskell.org> #14438: Using a (meaningless) generic currency sign (¤) instead of $ causes panicing ---------------------------------+-------------------------------------- Reporter: Izmaki | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: Component: GHCi | Version: 8.0.2 Resolution: duplicate | Keywords: ¤ Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13106 Comment: Thanks for the bug report. This is a duplicate of #13106, and has been fixed in GHC 8.2: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> let ones x = snd $ divMod x 10 λ> ones ¤ (5 :: Integral) :2:6: error: Variable not in scope: (¤) :: (b0 -> b0) -> t0 -> t1 :2:14: error: • Expecting one more argument to ‘Integral’ Expected a type, but ‘Integral’ has kind ‘* -> Constraint’ • In an expression type signature: Integral In the second argument of ‘(¤)’, namely ‘(5 :: Integral)’ In the expression: (¤) ones (5 :: Integral) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 21:22:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 21:22:50 -0000 Subject: [GHC] #14439: Remove redundant subtraction in (^) and stimes Message-ID: <047.009e2be896b30621f9e70dd019b082b1@haskell.org> #14439: Remove redundant subtraction in (^) and stimes -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.2.1 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: -------------------------------------+------------------------------------- Here is the source code of `Data.Real.^`: {{{#!hs (^) :: (Num a, Integral b) => a -> b -> a x0 ^ y0 | y0 < 0 = errorWithoutStackTrace "Negative exponent" | y0 == 0 = 1 | otherwise = f x0 y0 where -- f : x0 ^ y0 = x ^ y f x y | even y = f (x * x) (y `quot` 2) | y == 1 = x | otherwise = g (x * x) ((y - 1) `quot` 2) x -- g : x0 ^ y0 = (x ^ y) * z g x y z | even y = g (x * x) (y `quot` 2) z | y == 1 = x * z | otherwise = g (x * x) ((y - 1) `quot` 2) (x * z) }}} In both cases subtraction `y - 1` is redundant. The value of `y` is guaranteed to be positive and odd, so `(y - 1) `quot` 2 = y `quot` 2`. Same argument applies to `Data.Semigroup.Internal.stimes{Monoid,Default}`. For instance, {{{#!hs stimesMonoid :: (Integral b, Monoid a) => b -> a -> a stimesMonoid n x0 = case compare n 0 of LT -> errorWithoutStackTrace "stimesMonoid: negative multiplier" EQ -> mempty GT -> f x0 n where f x y | even y = f (x `mappend` x) (y `quot` 2) | y == 1 = x | otherwise = g (x `mappend` x) (pred y `quot` 2) x g x y z | even y = g (x `mappend` x) (y `quot` 2) z | y == 1 = x `mappend` z | otherwise = g (x `mappend` x) (pred y `quot` 2) (x `mappend` z) }}} Again, `pred y` is redundant; it is enough to divide `y` itself. My proposal is to replace `y - 1` and `pred y` by `y`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 21:28:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 21:28:40 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314438=3A_Using_a_=28meaningless=29_?= =?utf-8?q?generic_currency_sign_=28=C2=A4=29_instead_of_=24_caus?= =?utf-8?q?es_panicing?= In-Reply-To: <045.ca9f499c59ecff2bf0fd2b9591b2a709@haskell.org> References: <045.ca9f499c59ecff2bf0fd2b9591b2a709@haskell.org> Message-ID: <060.369303a83bc845434ae02dd342a938c5@haskell.org> #14438: Using a (meaningless) generic currency sign (¤) instead of $ causes panicing ---------------------------------+-------------------------------------- Reporter: Izmaki | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: Component: GHCi | Version: 8.0.2 Resolution: duplicate | Keywords: ¤ Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Izmaki): Ah, apologies for the duplicate. I wasn't able to find something similar when searching. Have a great evening, and thank you for making Haskell better :-) Replying to [comment:1 RyanGlScott]: > Thanks for the bug report. This is a duplicate of #13106, and has been fixed in GHC 8.2: > > {{{ > GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/rgscott/.ghci > λ> let ones x = snd $ divMod x 10 > λ> ones ¤ (5 :: Integral) > > :2:6: error: > Variable not in scope: (¤) :: (b0 -> b0) -> t0 -> t1 > > :2:14: error: > • Expecting one more argument to ‘Integral’ > Expected a type, but ‘Integral’ has kind ‘* -> Constraint’ > • In an expression type signature: Integral > In the second argument of ‘(¤)’, namely ‘(5 :: Integral)’ > In the expression: (¤) ones (5 :: Integral) > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 22:14:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 22:14:26 -0000 Subject: [GHC] #14391: Make the simplifier independent of the typechecker In-Reply-To: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> References: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> Message-ID: <061.47ca8139cb9514e4299ee6a5b9b31787@haskell.org> #14391: Make the simplifier independent of the typechecker -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great. I suggest you start with `TcEnv.lookupGlobal`. * It invokes `initTcForLookup` (massive overkill) in order to call `tcLookupGlobal`. We need a versionn of this function that operates in the IO monad, not the `TcM` monad. * What does `tcLookupGlobal` get from the `TcM` monad? It'll need to get these things as explicit arguments instead, I guess. For example: consults the `tcg_type_env`, which was initialised by `initTcForLookup`. And it uses `tcg_semantic_mod` likewise. * Then it hands off to `LoadIface.tcLookupImported_maybe`. That does a bit more IO-ish things before finally deciding to load a new interface decl in `tcImportDecl_maybe`. * `tcImportDecl_maybe` uses `initIfaceTcRn` to make an `IfM` moand in which to do the loading work. But instesad you can make an `IfM` from scratch, by writing a variant of `initIfaceTcRn`. Nothing really hard here, but you'll need to carefully tease out what dependencies are where. (The lack of explicit dependencies is, of course, both the blessing and the curse of monadic progrmaming.) Happy to help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 22:27:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 22:27:14 -0000 Subject: [GHC] #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.00eca580e61f042c0fd193119965f477@haskell.org> #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context -------------------------------------+------------------------------------- Reporter: cactus | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): All good points. Could you possibly offer a patch? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 22:30:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 22:30:54 -0000 Subject: [GHC] #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance In-Reply-To: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> References: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> Message-ID: <064.2331c5b93ad09e99f364a390814166de@haskell.org> #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | 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 simonpj): This is more fallout from `-fsolve-constant-dicts` see #12791. I have a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 22:31:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 22:31:20 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.fad0431a217cf1a5f759559daa807430@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5835, #13943, | Differential Rev(s): Phab:D2714 #14434 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * related: #5835, #13943 => #5835, #13943, #14434 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 22:46:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 22:46:37 -0000 Subject: [GHC] #14430: lintUnfolding does not allow unfoldings to jump to enclosing join points In-Reply-To: <046.6216ada2e885c6002a71b2409ce20404@haskell.org> References: <046.6216ada2e885c6002a71b2409ce20404@haskell.org> Message-ID: <061.0da8f44ec55779176f7fa0947a987fa6@haskell.org> #14430: lintUnfolding does not allow unfoldings to jump to enclosing join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): The key idea is this: an unfolding is like an extra RHS for the function. So yes, this is a bug. On inspection, it's caused by `lintUnfolding` being called in the wrong place: * We want `lintUnfolding` to be called, once for all, on the unfolding (if any) of each top-level Id; that is, in the `IfaceId` case of `tc_iface_decl`. * But it isn't! Instead `lintUnfolding` is called by `tcPragExpr`, which is called from `tcUnfolding` which is called for each nested unfolding in the interface-file declaration. * This is inefficient, because the top-level call will re-lint the nested unfoldings; and it's wrong for the reason you point out. In the olden days there were no nested unfoldings in interface0-file definitions, which is why this bug got started. Might you fix, Joachim? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 22:48:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 22:48:15 -0000 Subject: [GHC] #14430: lintUnfolding does not allow unfoldings to jump to enclosing join points In-Reply-To: <046.6216ada2e885c6002a71b2409ce20404@haskell.org> References: <046.6216ada2e885c6002a71b2409ce20404@haskell.org> Message-ID: <061.1bc30a79ab1df314efa41050e520c2b9@haskell.org> #14430: lintUnfolding does not allow unfoldings to jump to enclosing join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 nomeata): With these pointers, I can give it a shot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 22:48:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 22:48:28 -0000 Subject: [GHC] #14430: lintUnfolding does not allow unfoldings to jump to enclosing join points In-Reply-To: <046.6216ada2e885c6002a71b2409ce20404@haskell.org> References: <046.6216ada2e885c6002a71b2409ce20404@haskell.org> Message-ID: <061.187aba4aea8e456c939a9f2870d442de@haskell.org> #14430: lintUnfolding does not allow unfoldings to jump to enclosing join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: (none) => nomeata -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 23:13:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 23:13:08 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314395=3A_Redefining_pattern_synonym?= =?utf-8?q?_in_GHCi_triggers_=22=E2=80=98p=E2=80=99_is_untouchabl?= =?utf-8?q?e=22_error?= In-Reply-To: <050.cf61c6ee7a6236b0e7715eec7b752c2c@haskell.org> References: <050.cf61c6ee7a6236b0e7715eec7b752c2c@haskell.org> Message-ID: <065.cbf63086a9242b9becb3bc66c7f9c01f@haskell.org> #14395: Redefining pattern synonym in GHCi triggers "‘p’ is untouchable" error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): The error message is indeed confusing, but I think what is happening is this * You load `Bug.hs` * But the interactive context does not have `-XPatternSynonyms` * So when you say {{{ pattern Bar = Nothing }}} GHCi doesn't see `pattern` as a keyword; it sees it as a perfectly ordinary identifier. So its' as if you had written {{{ f Bar = Nothing }}} to define function `f`. * That's why it says, for example {{{ in an equation for ‘pattern’ }}} Quite right! This is a function definition for function `pattern`. It would be cool if it said "Perhaps you meant to use `PatternSynonuyms`" but I don't really see where to put such a test. Anyway I think it's a case of: not a bug, just a confusing error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 23:19:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 23:19:28 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.e3500431a3a777dd0b2868a909a72472@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): I wonder if anyone else can work with Andreas on this? I lack bandwidth. Very brief thoughts: * Giving two or three actual concrete examples where we get better code would be useful. * Comparing ''after'' simplification is quite important. If the simplifier automatically gets most of the benefit, it wouldn't be worth having a more complicated pattern-match compiler. * Do a `nofib` run with and without your patch. Is there any measurable difference? * How big is your patch? The existing pattern match compiler is already quite subtle; how hard was it to implement your new scheme? Bottom line: to justify the extra complexity and maintenance burden, we'd have to be convinced that some programs run a lot faster; or that many programs run a bit faster. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 23:21:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 23:21:07 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2314395=3A_Redefining_pattern_synonym?= =?utf-8?q?_in_GHCi_triggers_=22=E2=80=98p=E2=80=99_is_untouchabl?= =?utf-8?q?e=22_error?= In-Reply-To: <050.cf61c6ee7a6236b0e7715eec7b752c2c@haskell.org> References: <050.cf61c6ee7a6236b0e7715eec7b752c2c@haskell.org> Message-ID: <065.3ceeac815b5f240933934e22ccfa4e73@haskell.org> #14395: Redefining pattern synonym in GHCi triggers "‘p’ is untouchable" error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: invalid | 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 RyanGlScott): * status: new => closed * resolution: => invalid Comment: I'll be darned—you're absolutely right, I just lucked out with `pattern Bar :: Foo Int` and managed to get `pattern Bar = Nothing` (or really, `f Bar = Nothing`) to compile even in the absence of `PatternSynonyms`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 23:26:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 23:26:55 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.594a24d08e9970c004b0855610fbefa9@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: core-lint | case Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4160 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Simon asked me to note here that his remark in comment:9 about `checkCaseAlts` was a bit off. The `null alts` there is doing something a bit different: allowing case matches with no alternatives on "nearly- infinite" types like `Int#`. Pulling that test out actually makes the build fail. Why? That's not actually entirely clear to me. Somewhere in `Text` internals, we get a Core Lint error {{{ 5258 : warning: 5259 In a case alternative: (I# n#_a4mN :: Int#) 5260 Case expression with non-exhaustive alternatives 5261 case lvl_sfty n#_a4mN of wild_00 { } }}} This is slightly surprising, because the relevant `lvl_sfty` seems to be {{{ 29713 lvl_sfty :: Int# -> Int# 29714 [LclId, 29715 Arity=1, 29716 Str=x, 29717 Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, 29718 WorkFree=True, Expandable=True, Guidance=NEVER}] 29719 lvl_sfty 29720 = \ (n#_a4mW :: Int#) -> 29721 error 29722 @ 'IntRep 29723 @ Int# 29724 ($dIP_saA9 29725 `cast` (Sym (N:IP[0] <"callStack">_N _N) 29726 :: (CallStack :: *) ~R# (?callStack::CallStack :: Constraint))) 29727 (augment 29728 @ Char 29729 lvl_sftt 29730 (augment 29731 @ Char 29732 lvl_sftv 29733 (augment 29734 @ Char 29735 lvl_sftx 29736 (showSignedInt $fShow(,)1 (I# n#_a4mW) ([] @ Char))))) }}} which is just a call to `error`. One other question: the `exprIsHNF` error was clearly hosed, and badly so. But should we leave the `scrut_diverges` warning in place? That seems like it's useful, even if it's not reliable. If we decide to leave that in place, can/should we apply it to `Int#` and such as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 7 23:58:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Nov 2017 23:58:46 -0000 Subject: [GHC] #14440: Duplicate type family instances are permitted Message-ID: <050.a11e186e28ab55a8cab8e4cc675cfa2b@haskell.org> #14440: Duplicate type family instances are permitted -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: TypeFamilies | 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 threw me for a loop recently. To my surprise, GHC is quite happy to allow duplicate type family instances, provided that their RHSes are the same: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Lib where type family Foo b }}} {{{#!hs {-# LANGUAGE TypeFamilies #-} module A where import Lib type instance Foo Bool = Bool }}} {{{#!hs {-# LANGUAGE TypeFamilies #-} module B where import Lib type instance Foo Bool = Bool }}} {{{#!hs module C where import A import B import Lib f :: Bool -> Foo Bool f x = not x }}} {{{ $ /opt/ghc/8.2.1/bin/ghci C.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 4] Compiling Lib ( Lib.hs, interpreted ) [2 of 4] Compiling B ( B.hs, interpreted ) [3 of 4] Compiling A ( A.hs, interpreted ) [4 of 4] Compiling C ( C.hs, interpreted ) Ok, 4 modules loaded. λ> :i Foo type family Foo b :: * -- Defined at Lib.hs:4:1 type instance Foo Bool = Bool -- Defined at A.hs:6:15 type instance Foo Bool = Bool -- Defined at B.hs:6:15 }}} Is this intended? My intuition screams "no", since if we offer //class// instance coherence, it seems like one ought to offer //type family// instance coherence as well. At the same time, I can't think of any threat to type soundness imposed by this (although it's quite strange to see two duplicate type family instances in the output of `:i` with two completely different provenances). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 01:14:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 01:14:00 -0000 Subject: [GHC] #14441: GHC HEAD regression involving type families in kinds Message-ID: <050.cffc20d5c60287ccb30e96fd4e02f185@haskell.org> #14441: GHC HEAD regression involving type families in kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #13790 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In GHC 8.2.1, this file typechecks: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind type family Demote (k :: Type) :: Type type family DemoteX (a :: k) :: Demote k data Prox (a :: k) = P type instance Demote (Prox (a :: k)) = Prox (DemoteX a) $(return []) type instance DemoteX P = P }}} (Note that the `$(return [])` line is essential, as it works around #13790.) However, on GHC HEAD, this now fails: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:15:27: error: • Expected kind ‘Demote (Prox a0)’, but ‘P’ has kind ‘Prox a1’ • In the type ‘P’ In the type instance declaration for ‘DemoteX’ | 15 | type instance DemoteX P = P | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 02:35:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 02:35:57 -0000 Subject: [GHC] #14441: GHC HEAD regression involving type families in kinds In-Reply-To: <050.cffc20d5c60287ccb30e96fd4e02f185@haskell.org> References: <050.cffc20d5c60287ccb30e96fd4e02f185@haskell.org> Message-ID: <065.4a06ca751ea4d6658cfdfea9685f75d1@haskell.org> #14441: GHC HEAD regression involving type families in kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #13790 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: This was introduced in commit 74cd1be0b2778ad99566cde085328bde2090294a (`Don't deeply expand insolubles`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 05:15:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 05:15:02 -0000 Subject: [GHC] #14440: Duplicate type family instances are permitted In-Reply-To: <050.a11e186e28ab55a8cab8e4cc675cfa2b@haskell.org> References: <050.a11e186e28ab55a8cab8e4cc675cfa2b@haskell.org> Message-ID: <065.111e51e0c375078ba4011341d9d9d144@haskell.org> #14440: Duplicate type family instances are permitted -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeFamilies 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 AntC): Replying to [ticket:14440 RyanGlScott]: > Is this intended? I'm not sure if intended for identical type family instances, but it's certainly to be expected for partially overlapping type family instances. See examples in [https://downloads.haskell.org/~ghc/8.2.1/docs/html/users_guide/glasgow_exts.html #compatibility-and-apartness-of-type-family-equations User Guide]. > My intuition screams "no", since if we offer //class// instance coherence, it seems like one ought to offer //type family// instance coherence as well. The trouble with ''class'' instances is that we can't infer whether the rhs method expressions are equivalent in case of overlapping instance heads. Thus you can't have class instances with identical heads -- GHC doesn't try checking if the rhs's are identical. Contrariwise type family rhs's have a very simple structure, needing only alpha-renaming to determine if confluent. > At the same time, I can't think of any threat to type soundness imposed by this. Quite. And that's the point in the papers that introduced type families circa 2008. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 05:31:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 05:31:40 -0000 Subject: [GHC] #14440: Duplicate type family instances are permitted In-Reply-To: <050.a11e186e28ab55a8cab8e4cc675cfa2b@haskell.org> References: <050.a11e186e28ab55a8cab8e4cc675cfa2b@haskell.org> Message-ID: <065.95ac3019fd3bbde0b774a5105c190b2a@haskell.org> #14440: Duplicate type family instances are permitted -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeFamilies 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 AntC): Replying to [ticket:14440 RyanGlScott]: > My intuition screams "no", since if we offer //class// instance coherence, ... And the short answer to that is we '''don't''' offer and can't guarantee class instance coherence/consistency, if you're talking about FunDeps. See SPJ on [https://ghc.haskell.org/trac/ghc/ticket/10675#comment:15 'bogus consistency check']. (Sorry, but there's plenty of code abusing that consistency check, pioneered in GHC in the 2004 HList paper. Contrast Hugs never allowed such abuse. There is [https://github.com/ghc-proposals/ghc- proposals/pull/56 a way out]. Please upvote.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 05:38:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 05:38:24 -0000 Subject: [GHC] #14433: Windows10 GHCI Crash, it can't run correctly In-Reply-To: <046.b6bae8d51e87c7b5229b5e0810340119@haskell.org> References: <046.b6bae8d51e87c7b5229b5e0810340119@haskell.org> Message-ID: <061.259d32c7dfcb594fa8819776a717ea88@haskell.org> #14433: Windows10 GHCI Crash, it can't run correctly ----------------------------------+-------------------------------------- Reporter: Shizumi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by Shizumi): Replying to [comment:1 bgamari]: > Any idea what is going on here, Tamar? Still I don't know why,however,when I switch to version 8.0.2, there is no problem. BTW, I found a similiar error like me some days ago and I follow the suggestion there that install a API monitor and monitor ghc.exe,there are only two exe where should be four. Sorry for my poor English, Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 06:13:33 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 06:13:33 -0000 Subject: [GHC] #14410: Windows 10 freeze caused by infinite recursion in WinGHCi In-Reply-To: <046.1ddf55fb3dfb9f3b6345d9be1b918869@haskell.org> References: <046.1ddf55fb3dfb9f3b6345d9be1b918869@haskell.org> Message-ID: <061.7c554a9e25e496a015e8beba4ecf3ca0@haskell.org> #14410: Windows 10 freeze caused by infinite recursion in WinGHCi ------------------------------+---------------------------------------- Reporter: WinKlim | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #14150 | Differential Rev(s): Wiki Page: | ------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 06:17:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 06:17:14 -0000 Subject: [GHC] #14398: Fail to install haskell platform on Windows In-Reply-To: <045.d86ee14cadb946edd5536f02e4b96185@haskell.org> References: <045.d86ee14cadb946edd5536f02e4b96185@haskell.org> Message-ID: <060.3b57cf64dfa4dc39e3e0e279208c8158@haskell.org> #14398: Fail to install haskell platform on Windows -------------------------------------+------------------------------------- Reporter: KAAAsS | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #14168 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * related: => #14168 Comment: Thanks for 8.2 won't work with the monitor, so the output won't be very useful. I'll have to make a special build of 8.2 for you to check. I'll do that today. I am however curious as to why the 8.4 build works... can you still attach a log the traces for that one? It should contain the paths i'm after. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 06:19:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 06:19:30 -0000 Subject: [GHC] #83: typo: %lt; should be < In-Reply-To: <045.220364867156d950dbdf718612e7bbe7@haskell.org> References: <045.220364867156d950dbdf718612e7bbe7@haskell.org> Message-ID: <060.0ce7a17724df395687c3439dfbc9b1a4@haskell.org> #83: typo: %lt; should be < ---------------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 5.04.1 Resolution: Fixed | Keywords: Type of failure: None/Unknown | ---------------------------------+-------------------- Changes (by Mateusz Kowalczyk ): * failure: => None/Unknown Comment: In [changeset:"ed18f47f931361a9adbb109085c6feb432ec41aa/ghc" ed18f47/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ed18f47f931361a9adbb109085c6feb432ec41aa" Factor out builds into steps. Address ghc/ghc#83 comments. This should greatly improve log output. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 06:29:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 06:29:29 -0000 Subject: [GHC] #14433: Windows10 GHCI Crash, it can't run correctly In-Reply-To: <046.b6bae8d51e87c7b5229b5e0810340119@haskell.org> References: <046.b6bae8d51e87c7b5229b5e0810340119@haskell.org> Message-ID: <061.ece9ffa4b56e2c0f836ceac4e6439f4e@haskell.org> #14433: Windows10 GHCI Crash, it can't run correctly ----------------------------------+-------------------------------------- Reporter: Shizumi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14168 #14398 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => duplicate * related: => #14168 #14398 Comment: Let's continue this at #14398. This is locale related, it's having trouble converting char to a widechar, and seems to have some issues under what looks like a Chinese locale. 8.0 works because it doesn't have support for import libraries, so it doesn't have this call. The function that fails is `mbstowcs` and the documentation states: `If mbstowcs encounters an invalid multibyte character, it returns –1` So something is corrupting the path. This corruption was either introduced in 8.2 or always existed but we never knew it because the paths weren't being validated. Judging from #14168 which seems to indicate that there's some path corruption long before it hits the rts. Shizumi, can you as well try the steps in https://ghc.haskell.org/trac/ghc/ticket/14398#comment:3 there's a big possibility that 8.4 fixes the memory corruption by an unrelated commit, which is why it's working. but without the path I can't figure it out.. I'll have to make a special build of 8.2 with the aggressive error handlers turned off for the monitor to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 07:32:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 07:32:02 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.9294dcec014282f2e4a0bc3bdafe2e84@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): Further evidence, based on the observation that the problem is caused by certain kinds of CPS-style code: {{{ module Nested where -- A data type capturing the relevant structure of the P type from ReadP data A a = A (Int -> A a) | N a -- This implementation produces deeply nested Core: f10 :: A (Int, Int, Int, Int, Int, Int, Int, Int, Int, Int) f10 = A (\i0 -> A (\i1 -> A (\i2 -> A (\i3 -> A (\i4 -> A (\i5 -> A (\i6 -> A (\i7 -> A (\i8 -> A (\i9 -> N (i0, i1, i2, i3, i4, i5, i6, i7, i8, i9) )))))))))) -- This implementation produces flat Core. g10 :: A (Int, Int, Int, Int, Int, Int, Int, Int, Int, Int) g10 = a0 where {-#NOINLINE a10#-} a10 = \(i0, i1, i2, i3, i4, i5, i6, i7, i8) i9 -> N (i0, i1, i2, i3, i4, i5, i6, i7, i8, i9) {-#NOINLINE a9#-} a9 = \(i0, i1, i2, i3, i4, i5, i6, i7) i8 -> A (a10 (i0, i1, i2, i3, i4, i5, i6, i7, i8)) {-#NOINLINE a8#-} a8 = \(i0, i1, i2, i3, i4, i5, i6) i7 -> A (a9 (i0, i1, i2, i3, i4, i5, i6, i7)) {-#NOINLINE a7#-} a7 = \(i0, i1, i2, i3, i4, i5) i6 -> A (a8 (i0, i1, i2, i3, i4, i5, i6)) {-#NOINLINE a6#-} a6 = \(i0, i1, i2, i3, i4) i5 -> A (a7 (i0, i1, i2, i3, i4, i5)) {-#NOINLINE a5#-} a5 = \(i0, i1, i2, i3) i4 -> A (a6 (i0, i1, i2, i3, i4)) {-#NOINLINE a4#-} a4 = \(i0, i1, i2) i3 -> A (a5 (i0, i1, i2, i3)) {-#NOINLINE a3#-} a3 = \(i0, i1) i2 -> A (a4 (i0, i1, i2)) {-#NOINLINE a2#-} a2 = \i0 i1 -> A (a3 (i0, i1)) {-#NOINLINE a1#-} a1 = \i0 -> A (a2 i0) {-#NOINLINE a0#-} a0 = A a1 }}} This module tries to provoke "tupling up the free variables" in `g10`, and compare it to the naive implementation `f10`. I do not know yet whether this would actually produce any performance benefits though. The NOINLINE pragmas are needed by the way, otherwise GHC decides to inline the `a` functions, and we end up with a mess similar to `f10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 11:18:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 11:18:16 -0000 Subject: [GHC] #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance In-Reply-To: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> References: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> Message-ID: <064.f0689275f45b52437c0993e916cb3241@haskell.org> #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | 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 Simon Peyton Jones ): In [changeset:"30058b0e45e920319916be999de9c4d77da136e7/ghc" 30058b0e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="30058b0e45e920319916be999de9c4d77da136e7" Fix another dark corner in the shortcut solver The shortcut solver for type classes (Trac #12791) was eagerly solving a constaint from an OVERLAPPABLE instance. It happened to be the only one in scope, so it was unique, but since it's specfically flagged as overlappable it's really a bad idea to solve using it, rather than using the Given dictionary. This led to Trac #14434, a nasty and hard to identify bug. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 11:18:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 11:18:16 -0000 Subject: [GHC] #14394: Inferred type for pattern synonym has redundant equality constraint In-Reply-To: <050.9779b5323a2024633d6aeced4501599a@haskell.org> References: <050.9779b5323a2024633d6aeced4501599a@haskell.org> Message-ID: <065.ff68f9e0ac3485b3924756b72d5414dc@haskell.org> #14394: Inferred type for pattern synonym has redundant equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms, TypeInType 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:"2c2f3cea93733e0c6dd04e1d891082652dcf5ea1/ghc" 2c2f3ce/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2c2f3cea93733e0c6dd04e1d891082652dcf5ea1" Minimise provided dictionaries in pattern synonyms Trac #14394 showed that it's possible to get redundant constraints in the inferred provided constraints of a pattern synonym. This patch removes the redundancy with mkMinimalBySCs. To do this I had to generalise the type of mkMinimalBySCs slightly. And, to reduce confusing reversal, I made it stable: it now returns its result in the same order as its input. That led to a raft of error message wibbles, mostly for the better. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 11:18:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 11:18:16 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.5849e97308ea6a3f9ac7bca396ce7b3a@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5835, #13943, | Differential Rev(s): Phab:D2714 #14434 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"30058b0e45e920319916be999de9c4d77da136e7/ghc" 30058b0e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="30058b0e45e920319916be999de9c4d77da136e7" Fix another dark corner in the shortcut solver The shortcut solver for type classes (Trac #12791) was eagerly solving a constaint from an OVERLAPPABLE instance. It happened to be the only one in scope, so it was unique, but since it's specfically flagged as overlappable it's really a bad idea to solve using it, rather than using the Given dictionary. This led to Trac #14434, a nasty and hard to identify bug. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 11:18:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 11:18:16 -0000 Subject: [GHC] #14408: error in refineFromInScope In-Reply-To: <043.032c0bafda9f7e231689ab772d2b28a6@haskell.org> References: <043.032c0bafda9f7e231689ab772d2b28a6@haskell.org> Message-ID: <058.7bffc62c4b50cdc918fdf4e4dca865ca@haskell.org> #14408: error in refineFromInScope -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Simon Peyton Jones ): In [changeset:"fe6848f544c2a14086bcef388c46f4070c22d287/ghc" fe6848f5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fe6848f544c2a14086bcef388c46f4070c22d287" Fix in-scope set in simplifier This patch fixes Trac #14408. The problem was that the StaticEnv field of an ApplyToVar or Select continuation didn't have enough variables in scope. The fix is simple, and I documented the invariant in Note [StaticEnv invariant] in SimplUtils. No change in behaviour: this just stops an ASSERT from tripping. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 11:19:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 11:19:36 -0000 Subject: [GHC] #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance In-Reply-To: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> References: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> Message-ID: <064.8e87febf0684d97b447295696cb65c74@haskell.org> #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | typecheck/should_compile/T14434 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T14434 * status: new => merge Comment: Thank you for such a small repro case. Can you confirm that this patch fixes your actual application? Merge to 8.2.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 11:20:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 11:20:12 -0000 Subject: [GHC] #14408: error in refineFromInScope In-Reply-To: <043.032c0bafda9f7e231689ab772d2b28a6@haskell.org> References: <043.032c0bafda9f7e231689ab772d2b28a6@haskell.org> Message-ID: <058.25b708f0627bc3cfb3362ecb70403013@haskell.org> #14408: error in refineFromInScope -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I've been meaning to look at this for ages, so thanks for the prompt. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 11:21:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 11:21:09 -0000 Subject: [GHC] #14394: Inferred type for pattern synonym has redundant equality constraint In-Reply-To: <050.9779b5323a2024633d6aeced4501599a@haskell.org> References: <050.9779b5323a2024633d6aeced4501599a@haskell.org> Message-ID: <065.8efd95b2f0a2cd0d46db6da5f299a6e6@haskell.org> #14394: Inferred type for pattern synonym has redundant equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: fixed | PatternSynonyms, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_compile/T14394 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => patsyn/should_compile/T14394 * status: new => closed * resolution: => fixed Comment: Ha! Indeed. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 11:32:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 11:32:13 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.8526ed85f46b14af87762c4b9e029ad0@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: core-lint | case Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4160 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > But should we leave the scrut_diverges warning in place? You are referring to this code in the `Case` equation for `lintCoreExpr`: {{{ -- See Note [No alternatives lint check] ; when (null alts) $ do { checkL (not (exprIsHNF scrut)) (text "No alternatives for a case scrutinee in head-normal form:" <+> ppr scrut) ; checkWarnL scrut_diverges (text "No alternatives for a case scrutinee not known to diverge for sure:" <+> ppr scrut) } }}} Well, suppose `x :: T Bool`, where `T` is in comment:8. Then if I say something like {{{ case x of {} }}} then `x` is not sure to diverge but the case branches are legitimately empty. Maybe you can add an example like this in a `Note` explaining why there is no null-alts check here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 12:45:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 12:45:07 -0000 Subject: [GHC] #14440: Duplicate type family instances are permitted In-Reply-To: <050.a11e186e28ab55a8cab8e4cc675cfa2b@haskell.org> References: <050.a11e186e28ab55a8cab8e4cc675cfa2b@haskell.org> Message-ID: <065.2ec77327b995a533313ed6ccce87e443@haskell.org> #14440: Duplicate type family instances are permitted -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeFamilies 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): See Section 3.6 of the [https://www.microsoft.com/en- us/research/publication/closed-type-families-with-overlapping-equations/ Closed type families] paper. Having identical RHSs is a degenerate case of Definition 10. But perhaps it's so degenerate that it should be reported with a warning; I'm not sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 13:01:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 13:01:43 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.6080e3390d6f21808322c41086d51376@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 simonpj): Hmm. The `Cmm` for `g10` is actually a lot bigger than that for `f10`, and looked to me as if it too would scale quadratically. Are `f10` and `g10` accurate reflections of the "scale well" and "scale badly" versions of Read? I can see why things might scale badly, if we have a lot of {{{ p1 >>= \x -> p2 >>= \y -> p3 >>= \z -> return (K x y z) }}} And `f10` has that structure, albeit with data constructors rather than functions. BUT: if that's it, why doesn't `(>>=)` inline, so we get a case expression instead?? So if `f10` is reasonably accurate, I can see two ways forward: 1 Do something in the back end to generate less code. 2 Generate different code. I'm still intrigued (and a bit disbelieving) why a different exposition of Read generates code that scales better. Concerning (1) the kind of thing I had in mind was more like this {{{ f10 = A (\i0 -> A (\i1 -> A (\i2 -> A (\i3 -> A (\i4 -> let t = (i0,i1,i2,i3,i4) in A (\i5 -> A (\i6 -> A (\i7 -> A (\i8 -> A (\i9 -> case t of (i0,i1,i2,i3,i4) -> N (i0, i1, i2, i3, i4, i5, i6, i7, i8, i9) }}} Now no function closure gets more than 5 free variables. I imagine one could do this as a STG-to-STG transformation if we decided that this was really the core issue. A tantalising point is this. We have something like this: {{{ let f4 = [i0,i1,i2,i3] \i4 -> let f5 = [i0,i1,i2,i3, i4] \i5 -> ...blah... }}} The list before the `\` are the free vars of the closure. Inside the code for `f4` we have `f4`'s function closure in hand, with `i0...` in it. Rather than capturing `i0, i1...` as the free vars of f5, we could just store a pointer to `f4`'s function closure (it's a kind of tuple, after all) and fetch its free vars from there. It's as if we wanted to say {{{ let f4 = [i0,i1,i2,i3] \i4 -> let f5 = [f4, i4] \i5 -> ...blah... }}} with `f4` and `i4` being the free vars of `f5`'s closure. This would be a deeper change to the code generator, but it could make a lot of sense in cases where ''all'' of `f4`'s free variables are also free in `f5`. (If not all where, you might get a space leak by closing over `f4`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 13:08:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 13:08:02 -0000 Subject: [GHC] #14440: Duplicate type family instances are permitted In-Reply-To: <050.a11e186e28ab55a8cab8e4cc675cfa2b@haskell.org> References: <050.a11e186e28ab55a8cab8e4cc675cfa2b@haskell.org> Message-ID: <065.cbfa6c29e03e07840c1e8d9a7102b61b@haskell.org> #14440: Duplicate type family instances are permitted -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: invalid | Keywords: TypeFamilies 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 RyanGlScott): * status: new => closed * resolution: => invalid Comment: Ah, I wasn't aware that this had already been debated before. My apologies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 13:53:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 13:53:02 -0000 Subject: [GHC] #14441: GHC HEAD regression involving type families in kinds In-Reply-To: <050.cffc20d5c60287ccb30e96fd4e02f185@haskell.org> References: <050.cffc20d5c60287ccb30e96fd4e02f185@haskell.org> Message-ID: <065.658a1ec08bc6ccc16e96f3146fc23346@haskell.org> #14441: GHC HEAD regression involving type families in kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #13790 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: goldfire (added) Comment: Gah! This is a nice small test case thank you. In `TcFlatten.flatten_exact_fam_app_fully` I see {{{ -- NB: fsk's kind is already flattend because -- the xis are flattened ; return (mkTyVarTy fsk, maybeSubCo eq_rel (mkSymCo co) `mkTransCo` ret_co ) } }}} But the comment is a lie. With the `DemoteX` above, the `fsk` will have type `Demote k` for some kind `k`, which is not flat. So the flattener's invariant (that flattened types have flattened kinds) is not respected). And that is ultimately the reason that we don't kick out an inert constraint that we should. Richard, what do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 13:59:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 13:59:16 -0000 Subject: [GHC] #13795: :kind! is not expanding type synonyms anymore In-Reply-To: <045.9bd0a404a46fb5b0930c49818b8cb45d@haskell.org> References: <045.9bd0a404a46fb5b0930c49818b8cb45d@haskell.org> Message-ID: <060.9069ab1bd945c2973c50608eb46b5a4b@haskell.org> #13795: :kind! is not expanding type synonyms anymore -------------------------------------+------------------------------------- Reporter: Hjulle | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.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: | -------------------------------------+------------------------------------- Comment (by alpmestan): There's a proposal up [https://github.com/ghc-proposals/ghc- proposals/pull/79 on github]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 15:17:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 15:17:51 -0000 Subject: [GHC] #11812: Template Haskell can induce non-unique Uniques In-Reply-To: <047.c1baa8985653a0b59eeec1328ee66507@haskell.org> References: <047.c1baa8985653a0b59eeec1328ee66507@haskell.org> Message-ID: <062.01fdbaa117f81fb8387319cfe53be0c8@haskell.org> #11812: Template Haskell can induce non-unique Uniques -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.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: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > When quoting a Template Haskell expression (or type), you can get your > hands on renamed variables. These variables have assigned Uniques. If you > then use the same variable locally in ''different'' top-level > expressions, chaos can ensue. It's certainly expected that something > bizarre would happen if you used the same Unique twice within the same > scope, but it surprised me that using the same Unique twice in different > scopes would cause a problem. > > Below is the rather hard-won reduced test case: > > {{{ > {-# LANGUAGE TemplateHaskell, PolyKinds, RankNTypes, TypeFamilies #-} > > module Bug where > > import Language.Haskell.TH > import Data.Type.Equality > > type Const a b = a > > $( do ForallT [PlainTV n] _ _ <- [t| forall n. n |] > let noBang = Bang NoSourceUnpackedness NoSourceStrictness > return [ClosedTypeFamilyD > (TypeFamilyHead (mkName "F1") > [ KindedTV (mkName "a") (VarT n) > , PlainTV (mkName "b") ] > (KindSig (VarT n)) > Nothing) > [TySynEqn [VarT (mkName "a"), VarT (mkName "b")] > (ConT ''Const `AppT` VarT (mkName "a") > `AppT` (ConT (mkName "T1") `AppT` > VarT (mkName "a") > `AppT` > VarT (mkName "b")))] > ,DataD > [] > (mkName "T1") > [ KindedTV (mkName "a") (VarT n) > , PlainTV (mkName "b") > , PlainTV (mkName "c")] > Nothing > [NormalC (mkName "K1") > [(noBang, ConT ''(:~:) `AppT` VarT (mkName "c") > `AppT` (ConT (mkName "F1") `AppT` > VarT (mkName "a") > `AppT` > VarT (mkName "b")))]] > []]) > }}} > > This blob produces > > {{{ > type family F1 (a :: n_auRf) b :: n_auRf where > F1 a b = Const a (T1 a b) > data T1 (a :: n_auRf) b c = K1 ((:~:) c (F1 a b)) > }}} > > which compiles fine when typed in directly. Note that this hinges on the > `SigTv` behavior of kind variables in non-CUSK declarations, but I don't > think that's the nub of the problem. > > What happens is this: during renaming, the `n`s are renamed to have the > same `Unique`, because `n` is `Exact`. Type-checking invents `SigTv`s for > each `n`. Naturally, both `n`s have ''different'' `IORef`s stored in > their `TcTyVarDetails`. When the two `n`s are compared during checking, > though, their `Unique`s are the same, and so nothing happens -- even > though they should be unified. The upshot is that we get one logical > variable `n` with different `IORef`s in different occurrences, causing > chaos. > > It might be reasonable to punt on this, but we should document in the > manual what the problem is. It puzzled me for quite a while when the > problem came up in real code! New description: When quoting a Template Haskell expression (or type), you can get your hands on renamed variables. These variables have assigned Uniques. If you then use the same variable locally in ''different'' top-level expressions, chaos can ensue. It's certainly expected that something bizarre would happen if you used the same Unique twice within the same scope, but it surprised me that using the same Unique twice in different scopes would cause a problem. Below is the rather hard-won reduced test case: {{{ {-# LANGUAGE TemplateHaskell, PolyKinds, RankNTypes, TypeFamilies #-} module Bug where import Language.Haskell.TH import Data.Type.Equality type Const a b = a $(do ForallT [PlainTV n] _ _ <- [t| forall n. n |] let noBang = Bang NoSourceUnpackedness NoSourceStrictness return [ClosedTypeFamilyD (TypeFamilyHead (mkName "F1") [ KindedTV (mkName "a") (VarT n) , PlainTV (mkName "b") ] (KindSig (VarT n)) Nothing) [TySynEqn [VarT (mkName "a"), VarT (mkName "b")] (ConT ''Const `AppT` VarT (mkName "a") `AppT` (ConT (mkName "T1") `AppT` VarT (mkName "a") `AppT` VarT (mkName "b")))] ,DataD [] (mkName "T1") [ KindedTV (mkName "a") (VarT n) , PlainTV (mkName "b") , PlainTV (mkName "c")] Nothing [NormalC (mkName "K1") [(noBang, ConT ''(:~:) `AppT` VarT (mkName "c") `AppT` (ConT (mkName "F1") `AppT` VarT (mkName "a") `AppT` VarT (mkName "b")))]] []]) }}} This blob produces {{{ type family F1 (a :: n_auRf) b :: n_auRf where F1 a b = Const a (T1 a b) data T1 (a :: n_auRf) b c = K1 ((:~:) c (F1 a b)) }}} which compiles fine when typed in directly. Note that this hinges on the `SigTv` behavior of kind variables in non-CUSK declarations, but I don't think that's the nub of the problem. What happens is this: during renaming, the `n`s are renamed to have the same `Unique`, because `n` is `Exact`. Type-checking invents `SigTv`s for each `n`. Naturally, both `n`s have ''different'' `IORef`s stored in their `TcTyVarDetails`. When the two `n`s are compared during checking, though, their `Unique`s are the same, and so nothing happens -- even though they should be unified. The upshot is that we get one logical variable `n` with different `IORef`s in different occurrences, causing chaos. It might be reasonable to punt on this, but we should document in the manual what the problem is. It puzzled me for quite a while when the problem came up in real code! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 15:18:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 15:18:32 -0000 Subject: [GHC] #11812: Template Haskell can induce non-unique Uniques In-Reply-To: <047.c1baa8985653a0b59eeec1328ee66507@haskell.org> References: <047.c1baa8985653a0b59eeec1328ee66507@haskell.org> Message-ID: <062.418f0f95c366e9ba20310e3da56af369@haskell.org> #11812: Template Haskell can induce non-unique Uniques -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.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 RyanGlScott): To make things worse, this program now panics on GHC 8.2.1: {{{ $ /opt/ghc/8.2.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): expectJust zonkTcTyVarToVar CallStack (from HasCallStack): error, called at compiler/utils/Maybes.hs:53:27 in ghc:Maybes expectJust, called at compiler/typecheck/TcType.hs:1583:21 in ghc:TcType }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 16:45:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 16:45:12 -0000 Subject: [GHC] #14430: lintUnfolding does not allow unfoldings to jump to enclosing join points In-Reply-To: <046.6216ada2e885c6002a71b2409ce20404@haskell.org> References: <046.6216ada2e885c6002a71b2409ce20404@haskell.org> Message-ID: <061.6492a56c6eaeed199ba6f0b04a2f65cd@haskell.org> #14430: lintUnfolding does not allow unfoldings to jump to enclosing join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.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:D4169 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D4169 Comment: See https://phabricator.haskell.org/D4169 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 8 21:20:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Nov 2017 21:20:41 -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.7fd38b9e8d2c6a0e02eb4e331f99ba1c@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): Replying to [comment:30 ekmett]: > I'm not particularly wedded to whether I use > > {{{#!hs > type family Gcd :: Nat -> Nat -> Nat > }}} > > or > > {{{#!hs > type family Gcd (n:: Nat) (m::Nat) :: Nat > }}} > > here. > > The one thing I have in favor (or against, depending on your perspective) of the Nat -> Nat -> Nat encoding is that it allows me to preclude the user actually defining any ad hoc base cases. Switching to the other address the "eta" concern to some extent. Doesn't an empty closed type family serve the same purpose? The first encoding seems simply wrong, because it implies that `Gcd` is injective. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 00:11:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 00:11:01 -0000 Subject: [GHC] #14430: lintUnfolding does not allow unfoldings to jump to enclosing join points In-Reply-To: <046.6216ada2e885c6002a71b2409ce20404@haskell.org> References: <046.6216ada2e885c6002a71b2409ce20404@haskell.org> Message-ID: <061.aac6f0086531474543150a4566c1408f@haskell.org> #14430: lintUnfolding does not allow unfoldings to jump to enclosing join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.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:D4169 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"803ed036704aa5bab8b0f1fee407e58d82c85393/ghc" 803ed036/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="803ed036704aa5bab8b0f1fee407e58d82c85393" Invoke lintUnfolding only on top-level unfoldings (#14430) as nested unfoldings are linted together with the top-level unfolding, and lintUnfolding does the wrong things for nestd unfoldings that mention join points. The easiest way of doing that was to pass a TopLevel flag through `tcUnfolding`, which is invoked both for top level and nested unfoldings. Differential Revision: https://phabricator.haskell.org/D4169 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 00:11:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 00:11:19 -0000 Subject: [GHC] #14430: lintUnfolding does not allow unfoldings to jump to enclosing join points In-Reply-To: <046.6216ada2e885c6002a71b2409ce20404@haskell.org> References: <046.6216ada2e885c6002a71b2409ce20404@haskell.org> Message-ID: <061.4401217e41aa559108d9be920d88bf9b@haskell.org> #14430: lintUnfolding does not allow unfoldings to jump to enclosing join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4169 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 00:39:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 00:39:22 -0000 Subject: [GHC] #14432: Outdated comment in GHC.Real In-Reply-To: <047.5338823393ca6b66c7faac41f6269e57@haskell.org> References: <047.5338823393ca6b66c7faac41f6269e57@haskell.org> Message-ID: <062.4e71f00ec0b8f9a89f367d1411ccc35c@haskell.org> #14432: Outdated comment in GHC.Real -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: Bodigrim Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4171 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Bodigrim): * owner: (none) => Bodigrim * differential: => D4171 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 00:40:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 00:40:17 -0000 Subject: [GHC] #14432: Outdated comment in GHC.Real In-Reply-To: <047.5338823393ca6b66c7faac41f6269e57@haskell.org> References: <047.5338823393ca6b66c7faac41f6269e57@haskell.org> Message-ID: <062.a05276cad51f5c5b93efdb187a512dca@haskell.org> #14432: Outdated comment in GHC.Real -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: Bodigrim Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4171 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Bodigrim): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 00:42:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 00:42:13 -0000 Subject: [GHC] #14339: GHC 8.2.1 regression when combining GND with TypeError (solveDerivEqns: probable loop) In-Reply-To: <050.71c0075dc8f8df8e6578520d1b23a3ca@haskell.org> References: <050.71c0075dc8f8df8e6578520d1b23a3ca@haskell.org> Message-ID: <065.f97409b7990296ddc9dd0abc4d20db83@haskell.org> #14339: GHC 8.2.1 regression when combining GND with TypeError (solveDerivEqns: probable loop) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: deriving, Resolution: fixed | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | testsuite/tests/deriving/should_compile/T14339 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in a05d71a73048df005c924f023607005a327e2adf. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 00:42:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 00:42:38 -0000 Subject: [GHC] #14427: GHCi output change breaks tooling users In-Reply-To: <046.9530f469625f9852b11e9932b67ea56e@haskell.org> References: <046.9530f469625f9852b11e9932b67ea56e@haskell.org> Message-ID: <061.1b77ac9bc68fff71dbd4514242276f9f@haskell.org> #14427: GHCi output change breaks tooling users -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: GHCi | Version: 8.2.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:D4164 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in befd937353bee0f65197317410cde3f49fca521a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 12:20:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 12:20:13 -0000 Subject: [GHC] #10514: Generic for existential types In-Reply-To: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> References: <051.d185121bcf194fc1021cab90b66f9d08@haskell.org> Message-ID: <066.b0f0157c840eb75ba5184fab9cac6cb1@haskell.org> #10514: Generic for existential types -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8560 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 14:00:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 14:00:56 -0000 Subject: [GHC] #14442: InstanceSigs fails Message-ID: <051.92c083a904342cf57cdbf67ba298e591@haskell.org> #14442: InstanceSigs fails -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: InstanceSigs | 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 may be expected behavior, resulting from instance signatures being allowed to be "more polymorphic" than the method `@Bool`. But better safe than sorry (can't think of a better title). This works fine: {{{#!hs {-# Language KindSignatures, GADTs, DataKinds, TypeOperators, PolyKinds, TypeFamilies, TypeFamilyDependencies, InstanceSigs #-} import Data.Kind import Data.Type.Equality type family Sing = (res :: k -> Type) | res -> k type instance Sing = SBool data SBool :: Bool -> Type where SFalse :: SBool False STrue :: SBool True class EQ a where eq :: Sing (x::a) -> Sing (y::a) -> Maybe (x :~~: y) instance EQ Bool where eq :: Sing (x :: Bool) -> Sing (y :: Bool) -> Maybe (x :~~: y) eq SFalse SFalse = Just HRefl }}} Removing the kind annotation from `x :: Bool` and/or `y :: Bool` causes it to fail: Here I have removed it from `x`: `eq :: Sing x -> Sing (y :: Bool) -> Maybe (x :~~: y)` {{{ $ ghci -ignore-dot-ghci B.hs GHCi, version 8.3.20170920: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( B.hs, interpreted ) B.hs:19:6: error: • Couldn't match type ‘SBool’ with ‘Sing’ Expected type: Sing x Actual type: SBool a0 • In the pattern: SFalse In an equation for ‘eq’: eq SFalse SFalse = Just HRefl In the instance declaration for ‘EQ Bool’ • Relevant bindings include eq :: Sing x -> Sing y -> Maybe (x :~~: y) (bound at B.hs:19:3) | 19 | eq SFalse SFalse = Just HRefl | ^^^^^^ B.hs:19:22: error: • Could not deduce: (x :: k1) ~~ ('False :: Bool) from the context: a0 ~ 'False bound by a pattern with constructor: SFalse :: SBool 'False, in an equation for ‘eq’ at B.hs:19:6-11 or from: y ~ 'False bound by a pattern with constructor: SFalse :: SBool 'False, in an equation for ‘eq’ at B.hs:19:13-18 ‘x’ is a rigid type variable bound by the type signature for: eq :: forall k1 (x :: k1) (y :: Bool). Sing x -> Sing y -> Maybe (x :~~: y) at B.hs:18:9-54 Expected type: Maybe (x :~~: y) Actual type: Maybe (x :~~: x) • In the expression: Just HRefl In an equation for ‘eq’: eq SFalse SFalse = Just HRefl In the instance declaration for ‘EQ Bool’ • Relevant bindings include eq :: Sing x -> Sing y -> Maybe (x :~~: y) (bound at B.hs:19:3) | 19 | eq SFalse SFalse = Just HRefl | ^^^^^^^^^^ Failed, 0 modules loaded. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 14:11:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 14:11:17 -0000 Subject: [GHC] #14442: InstanceSigs fails In-Reply-To: <051.92c083a904342cf57cdbf67ba298e591@haskell.org> References: <051.92c083a904342cf57cdbf67ba298e591@haskell.org> Message-ID: <066.1a8d6a49030d0affd6ed30a813bccda6@haskell.org> #14442: InstanceSigs fails -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: InstanceSigs 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): Suppose you'd written the instance decl like this {{{ instance EQ Bool where eq = my_eq my_eq :: Sing (x :: Bool) -> Sing (y :: Bool) -> Maybe (x :~~: y) my_eq SFalse SFalse = Just HRefl }}} That works. Now remove the kind signature on `x :: Bool`. Fails. And indeed it should, because `my_eq`'s signature means {{{ my_eq :: forall k (x::k) (y::Bool). Sing x -> Sing (y :: Bool) -> Maybe (x :~~: y) }}} and indeed the code does not have this type. So I think it's behaving right. Can you suggest a concrete improvement to the user manual that would make that clearer? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 15:24:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 15:24:56 -0000 Subject: [GHC] #11962: Support induction recursion In-Reply-To: <047.045273ef2ac55a0385e215af795b4757@haskell.org> References: <047.045273ef2ac55a0385e215af795b4757@haskell.org> Message-ID: <062.eba6becd473f195ce8a4cb8b561b0bea@haskell.org> #11962: Support induction recursion -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9269 | Blocking: Related Tickets: #13901 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): @goldfire To my understanding, the priority of this ticket is getting induction recursion supported for GADTs. I'm unclear on how the "same recursive subgroup" error in the example you gave is related to the "same recursive subgroup" error that I run into with typeclasses. For example: {{{ class Grounded v where type Rep (a :: v) :: RuntimeRep type Lifted (a :: v) :: Type type Unlifted (a :: v) :: TYPE (Rep a) ... some methods in here as well }}} This currently errors with: {{{ sorted_int_type.hs:100:35: error: • Type constructor ‘Rep’ cannot be used here (it is defined and used in the same recursive group) • In the first argument of ‘TYPE’, namely ‘(Rep a)’ In the kind ‘TYPE (Rep a)’ | 100 | type Unlifted (a :: v) :: TYPE (Rep a) | ^^^ }}} I have to split the class up: {{{ class GroundSuper v where type Rep (a :: v) :: RuntimeRep class GroundSuper v => Grounded v where type Lifted (a :: v) :: Type type Unlifted (a :: v) :: TYPE (Rep a) }}} It's not the worst thing ever, but it's kind of silly that what really is logically one typeclass needs to be split up into two typeclasses. It's not totally clear to me if this is really even the same issue as what you describe above or if fixing one automatically fixes the other, but it gives the same error message, which leads me to believe that they are somehow related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 15:42:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 15:42:25 -0000 Subject: [GHC] #14443: Add a plugin phase that allows users to modify HsSyn before the desugarer Message-ID: <047.db01a8d384aae8d61e8f07147cee7c20@haskell.org> #14443: Add a plugin phase that allows users to modify HsSyn before the desugarer -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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'm currently playing around with a little project that attempts to replicate py.test. For context about py.test, see https://docs.pytest.org/en/latest/example/reportingdemo.html#tbreportdemo, but essentially it's a Python library that provides an `assert :: Bool -> IO ()` function, with the magic that if the assertion fails, it shows you some context about the `Bool` expression: {{{ def test_simple(self): def f(): return 42 def g(): return 43 > assert f() == g() E assert 42 == 43 }}} For example, shows that `f()` evaluated to 42. I'd like to do something like this for Haskell, and a GHC plugin seemed like the right place to do this. I first wrote a core-to-core plugin (https://github.com/ocharles/assert- explainer/blob/e6a669680cd214f23a4213e2f945f4468998fb1d/plugin/AssertExplainer.hs) which finds free variables and and attempts to `Show` them. This works, but I'd like to do more. As an example of something I'd like to do, I would like to let my users write `assert (and [x > 0 | x <- [-1, 0])`. This is a failing assertion, and I would like to show a kind of evaluation trace, something like {{{ and [x > 0 | x <- [-1, 0] = and [False, False] = False }}} To do this, I really need access to `HsSyn`, not `CoreExpr`. Template Haskell won't do, because I don't know what I can `Show` - I really need access to the type checker as well. A plugin that fires right before the desugarer would be really nice for this kind of task. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 16:45:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 16:45:59 -0000 Subject: [GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects Message-ID: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> #14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Keywords: | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm opening a fresh ticket as @bgamari suggested in #12479. There are few more related closed tickets as well: #12198 and #12588. The issue occurs on projects with a lot of dependencies. There are reports of that happening across various projects: [https://github.com/NixOS/nixpkgs/issues/22810] [https://github.com/commercialhaskell/stack/issues/2577] I'm still able to reproduce it with 8.2.1 and git HEAD with a work project: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/f8/2_rc4tgd1gj9vbgv7q9gbk4c0000gn/T/ghc94377_0/libghc_325.dylib, 5): no suitable image found. Did find: /var/folders/f8/2_rc4tgd1gj9vbgv7q9gbk4c0000gn/T/ghc94377_0/libghc_325.dylib: malformed mach-o: load commands size (34592) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I can't share the sources, but this is a command(generated by stack) that results in this error: `/Users/dr/.stack/setup-exe-cache/x86_64-osx/Cabal- simple_mPHDZzAJ_2.0.0.2_ghc-8.2.1 --builddir=.stack- work/dist/x86_64-osx/Cabal-2.0.0.2 build lib:projectname exe:projectname --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"` We're having a chat about this issue with @bgamari and I'll post some of his input: {{{ bgamari: dredozubov, unfortunately this is pretty much a limitation of OS X's linker bgamari: there's no great solution other than petitioning Apple to lift their arbitrary size limit bgamari: I've been asking people to open tickets with Apple bgamari: As they are really the only ones that can really fix this issue dredozubov: bgamari, do you know if someone did this already? bgamari: dredozubov, No one has said they have dredozubov: the other issue with it, I don't how to do a repro case dredozubov: I can reproduce it on a project with a closed sources and that's it bgamari: essentially you just need to build a project with enough dependencies bgamari: the problem is that Apple's linker sets an artificial cap on the number of shared libraries that an object file can load }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 17:45:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 17:45:41 -0000 Subject: [GHC] #14441: GHC HEAD regression involving type families in kinds In-Reply-To: <050.cffc20d5c60287ccb30e96fd4e02f185@haskell.org> References: <050.cffc20d5c60287ccb30e96fd4e02f185@haskell.org> Message-ID: <065.8aab7d9f3763761d84c0c91dab9ca6d9@haskell.org> #14441: GHC HEAD regression involving type families in kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #13790 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): We have in play #12919, which completely rewrites the flattening code. It also fixes at least six other tickets: the current setup is outright wrong. So Richard and I propose to park this bug and return to it when #12919 is committed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 17:46:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 17:46:24 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.7bea3e9421fe83d380a462dad99c0803@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12919 Blocked By: | Blocking: Related Tickets: #13643 | Differential Rev(s): Phab:D3848 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See also #14441, which may be fixed when we commit Phab:D3848. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 17:46:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 17:46:40 -0000 Subject: [GHC] #14441: GHC HEAD regression involving type families in kinds In-Reply-To: <050.cffc20d5c60287ccb30e96fd4e02f185@haskell.org> References: <050.cffc20d5c60287ccb30e96fd4e02f185@haskell.org> Message-ID: <065.e390399815250b3419ea6e0d1fe215d8@haskell.org> #14441: GHC HEAD regression involving type families in kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 12919 | Blocking: Related Tickets: #13790 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * blockedby: => 12919 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 18:40:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 18:40:34 -0000 Subject: [GHC] #14391: Make the simplifier independent of the typechecker In-Reply-To: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> References: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> Message-ID: <061.6b89cd81f2d29bf3c64edc9ccec6fc46@haskell.org> #14391: Make the simplifier independent of the typechecker -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jkiefer): Alrighty! First question while I investigate more into performing a minimal lookup instead of using `initTcForLookup`. (Bear with me, I'm writing some of this out as I understand it myself) We want to refactor `thNameToGhcName` to no longer be a part of CoreMonad and instead exist in a module to be pulled by `GhcPlugins.hs`. Do correct me if I'm wrong, but creating a singleton module with just `thNameToGhcName` in it seems like a naive approach. Is there an existing module that is pulled in by `GhcPlugins.hs`that would be an appropriate home for `thNameToGhcName`? Or should a new one simply be created? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 19:24:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 19:24:46 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.301e5af9322207a4aca59c54cab804a9@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12919 Blocked By: | Blocking: 14441 Related Tickets: #13643 | Differential Rev(s): Phab:D3848 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): For the record: this patch should fix this ticket, #13643, #13822, #14024, #14126, #14038, #13910, #13938. It's hard for me to say how it affects #14441, but Simon's analysis suggests that the problem stems from this ticket as well. The ticket is held up because of some performance trouble, but we'll get it in eventually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 19:38:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 19:38:43 -0000 Subject: [GHC] #11962: Support induction recursion In-Reply-To: <047.045273ef2ac55a0385e215af795b4757@haskell.org> References: <047.045273ef2ac55a0385e215af795b4757@haskell.org> Message-ID: <062.99ce6011dcdddb59ed303ad9112feb95@haskell.org> #11962: Support induction recursion -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9269 | Blocking: Related Tickets: #13901 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): comment:9 is certainly related, but still separate from the eventual goal of this ticket. I do think a fix for this ticket would fix comment:9, but comment:9 could also be fixed independently (and, I believe, more easily). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 19:49:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 19:49:13 -0000 Subject: [GHC] #14119: Refactor type patterns In-Reply-To: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> References: <047.bf8d1a6935e161be73f38f5b1322f10b@haskell.org> Message-ID: <062.714b723e5f101db4f5709e52faede388@haskell.org> #14119: Refactor type patterns -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12564, 13910, | 13938, 14038 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Conor McBride suggested to Simon today that we could usefully include lots of casts in patterns -- indeed, perhaps we should allow a cast essentially at all points in the pattern grammar. These casts would all be casts by a variable. Then, when matching, if the target has no cast at that spot, the variable is matched with Refl. This approach has the downside of producing big substitutions (with lots of type variables and coercion variables), but it has the upside of likely working. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 20:52:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 20:52:04 -0000 Subject: [GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects In-Reply-To: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> References: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> Message-ID: <064.668be1b673a2eb7fbe707a55501ce7b9@haskell.org> #14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | 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 bgamari): For the record, angerman has suggested in the past that we leverage recursive linking to work around this limitation. He has an example [[https://github.com/angerman/dylib-linking|here]]. However, I'll admit I'm not terribly keen on spending our complexity budget working around arbitrary limitations imposed by Apple. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 20:55:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 20:55:46 -0000 Subject: [GHC] #14361: GHC HEAD miscompiles `text-containers` In-Reply-To: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> References: <042.4be1bbae1efce089b6c1063178d01328@haskell.org> Message-ID: <057.e1d829f65788c58c4861716c388087a3@haskell.org> #14361: GHC HEAD miscompiles `text-containers` -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Whoops, this doesn't affect 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 21:15:30 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 21:15:30 -0000 Subject: [GHC] #14445: GC timing stats (e.g. mutator_elapsed_ns) decrease over time Message-ID: <047.81a01718a79512286f0bf0342273b9da@haskell.org> #14445: GC timing stats (e.g. mutator_elapsed_ns) decrease over time -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See this measurement code here in the `gauge` benchmarking tool, which is a clone of the criterion benchmarking tool. : https://github.com/harendra-kumar/hs- gauge/blob/f8c9bcd6ee03c3090f110664ff279a20f2da9130/Gauge/Measurement.hs#L315 . This code displays debug prints when the end time is lower than the start time for `mutator_elapsed_ns`. When we run this benchmark defined in https://github.com/harendra-kumar /hs-gauge/blob/f8c9bcd6ee03c3090f110664ff279a20f2da9130/benchs/GCBug.hs the following output is produced: {{{ $ stack bench --benchmark-arguments "--quick" gauge-0.1.3: benchmarks Running 1 benchmarks... Benchmark gcbug: RUNNING... benchmarking streamingDecreased by: 25818791 : s = 59840178 e = 34021387 Decreased by: 22707134 : s = 76706673 e = 53999539 Decreased by: 4776100 : s = 96201146 e = 91425046 streaming time 50.00 ms benchmarking pipesDecreased by: 12487955 : s = 153949495 e = 141461540 pipes time 50.00 ms benchmarking conduitDecreased by: 5523916 : s = 310913002 e = 305389086 conduit time 50.00 ms Benchmark gcbug: FINISH }}} Notice the "Decreased by" getting printed quite a few times. I have found it to be more likely for these particular libraries i.e. streaming, pipes and conduit; so I have used only these in the benchmarking file `GCBug.hs`. I tried some other streaming libraries as well but it did not occur often in those cases. In these cases it occurs almost every time. I am running it on a macbook. The repository is here: https://github.com/harendra-kumar/hs-gauge/tree /gc-bug . The branch in the repo is `gc-bug`. You can run the benchmark named `gcbug` using the command `stack bench --benchmark-arguments "-- quick"` to reproduce the output above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 21:20:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 21:20:12 -0000 Subject: [GHC] #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance In-Reply-To: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> References: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> Message-ID: <064.aaca0031d73efa1f83f3d25a26305b77@haskell.org> #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | typecheck/should_compile/T14434 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dredozubov): Thanks for the fix! Unfortunately I was unable to build our application with ghc HEAD due to broken dependencies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 21:25:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 21:25:13 -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.76644127ebd0a2174d7fcee2aa5c6df8@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: | -------------------------------------+------------------------------------- Comment (by heisenbug): Isn't this implemented now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 21:28:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 21:28:51 -0000 Subject: [GHC] #14391: Make the simplifier independent of the typechecker In-Reply-To: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> References: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> Message-ID: <061.4687448b393adc8b3e9ae50b9a687126@haskell.org> #14391: Make the simplifier independent of the typechecker -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I suggest you start with `TcEnv.lookupGlobal`. Doing this will avoid you getting sucked into template haskell stuff right away. We can come back to your question when this is done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 22:36:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 22:36:04 -0000 Subject: [GHC] #14446: Extending TypeApplications to support infix functions Message-ID: <049.464ef058942aef80120ed6efe1ff4857@haskell.org> #14446: Extending TypeApplications to support infix functions -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 a motivational example I propose a piece of code using a library [https://github.com/typeable/schematic], which defines a fancy record-like object and requires some type annotations: {{{ jsonExample = withRepr @SchemaExample $ field @"foo" [12] :& field @"bar" (Just "bar") :& RNil }}} By using the same function as an infix operator, it may be possible to rewrite it to something along the lines of {{{ (.=) = field jsonExample = withRepr @SchemaExample $ @"foo" .= [12] :& @"bar" .= (Just "bar") :& RNil }}} To do that, we'll need to associate a type application with the function to the right of it. I imagine it'll introduce ambiguity to the parser, but it can be dealt with by allowing a different syntactical construct for a right type application. Haven't checked with a grammar, but it can be something like this: {{{ jsonExample = withRepr @SchemaExample $ "foo"@ .= [12] :& "bar"@ .= (Just "bar") :& RNil }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 22:37:42 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 22:37:42 -0000 Subject: [GHC] #14445: GC timing stats (e.g. mutator_elapsed_ns) decrease over time In-Reply-To: <047.81a01718a79512286f0bf0342273b9da@haskell.org> References: <047.81a01718a79512286f0bf0342273b9da@haskell.org> Message-ID: <062.7b186f27785899b9f306776f1e42e9e3@haskell.org> #14445: GC timing stats (e.g. mutator_elapsed_ns) decrease over time -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #14257, #14006, | Differential Rev(s): #11645 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #14257, #14006, #11645 Comment: This may be related to the issues seen elsewhere with profiling (e.g. #14257, #14006, #11645). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 22:52:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 22:52:53 -0000 Subject: [GHC] #14268: Implement Explicit Foralls Proposal In-Reply-To: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> References: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> Message-ID: <061.6d8a1ec7fad5f374aec3d69f7e46dcd3@haskell.org> #14268: Implement Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: johnleo | Owner: johnleo Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13809 | Differential Rev(s): D4046 Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * differential: => D4046 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 22:54:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 22:54:33 -0000 Subject: [GHC] #14268: Implement Explicit Foralls Proposal In-Reply-To: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> References: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> Message-ID: <061.3901cea2e132e8834871016d20b3acdd@haskell.org> #14268: Implement Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: johnleo | Owner: johnleo Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13809 | Differential Rev(s): Phab:D4046 Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * differential: D4046 => Phab:D4046 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 23:34:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 23:34:54 -0000 Subject: [GHC] #14425: approxRational is wrong when (rat - eps) overflows in negative direction In-Reply-To: <046.eb71da6200dae7e365172a0968ad4790@haskell.org> References: <046.eb71da6200dae7e365172a0968ad4790@haskell.org> Message-ID: <061.678e42c825608432ea5681ccbaff18c0@haskell.org> #14425: approxRational is wrong when (rat - eps) overflows in negative direction -------------------------------------+------------------------------------- Reporter: danielk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: T14425 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4168 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ce9a67784390735aa9749667934af49665b8402e/ghc" ce9a6778/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ce9a67784390735aa9749667934af49665b8402e" base: Add test for #14425 Test Plan: Validate Reviewers: hvr Subscribers: rwbarton, thomie GHC Trac Issues: #14425 Differential Revision: https://phabricator.haskell.org/D4166 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 23:34:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 23:34:54 -0000 Subject: [GHC] #14432: Outdated comment in GHC.Real In-Reply-To: <047.5338823393ca6b66c7faac41f6269e57@haskell.org> References: <047.5338823393ca6b66c7faac41f6269e57@haskell.org> Message-ID: <062.39c23504334adc64b712dd4a26a2adae@haskell.org> #14432: Outdated comment in GHC.Real -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: Bodigrim Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4171 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0656cb4add7c45382f6a5c3234ad5c75d3e5f112/ghc" 0656cb4a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0656cb4add7c45382f6a5c3234ad5c75d3e5f112" Update comment in GHC.Real (trac#14432) Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14432 Differential Revision: https://phabricator.haskell.org/D4171 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 23:34:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 23:34:54 -0000 Subject: [GHC] #14425: approxRational is wrong when (rat - eps) overflows in negative direction In-Reply-To: <046.eb71da6200dae7e365172a0968ad4790@haskell.org> References: <046.eb71da6200dae7e365172a0968ad4790@haskell.org> Message-ID: <061.004772ed81955749aa93f694faf46e9b@haskell.org> #14425: approxRational is wrong when (rat - eps) overflows in negative direction -------------------------------------+------------------------------------- Reporter: danielk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: T14425 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4168 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c59d6da8639fd88919090b29cf4e76c4d0d8bbde/ghc" c59d6da/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c59d6da8639fd88919090b29cf4e76c4d0d8bbde" base: Normalize style of approxRational Stumbled upon this odd bit of style while looking at #14425. Usually I don't like to do this sort of reformatting, but this seemed like it would be necessary in the course fo fixing #14425. Reviewers: hvr Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4168 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 23:34:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 23:34:54 -0000 Subject: [GHC] #14425: approxRational is wrong when (rat - eps) overflows in negative direction In-Reply-To: <046.eb71da6200dae7e365172a0968ad4790@haskell.org> References: <046.eb71da6200dae7e365172a0968ad4790@haskell.org> Message-ID: <061.91e1b6e6f3e28eb85a9adf4043f1de89@haskell.org> #14425: approxRational is wrong when (rat - eps) overflows in negative direction -------------------------------------+------------------------------------- Reporter: danielk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: T14425 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4168 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5834da4872877736eefb85daedaf7b137ae702a1/ghc" 5834da48/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5834da4872877736eefb85daedaf7b137ae702a1" base: Fix #14425 Test Plan: Validate Reviewers: hvr Subscribers: rwbarton, thomie GHC Trac Issues: #14425 Differential Revision: https://phabricator.haskell.org/D4167 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 23:34:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 23:34:54 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.75507b316f0eece4813af1e1e262f0e6@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1-rc3 Resolution: | Keywords: core-lint | case Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4160 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6b52b4c832f888f7741a4ba0fec1fdac10244f6d/ghc" 6b52b4c8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6b52b4c832f888f7741a4ba0fec1fdac10244f6d" Remove unreliable Core Lint empty case checks Trac #13990 shows that the Core Lint checks for empty case are unreliable, and very hard to make reliable. The consensus (among simonpj, nomeata, and goldfire) seems to be that they should be removed altogether. Do that. Add test Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13990 Differential Revision: https://phabricator.haskell.org/D4161 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 23:34:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 23:34:54 -0000 Subject: [GHC] #5889: -fno-prof-count-entries leads to linking errors In-Reply-To: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> References: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> Message-ID: <058.338223c7c39fd33b92a77aa1d46d0ef1@haskell.org> #5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e6b13c963d0b54099a41bb1b51fe680644582051/ghc" e6b13c96/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e6b13c963d0b54099a41bb1b51fe680644582051" testsuite: Add test for #5889 Test Plan: make test TEST=5889 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #5889 Differential Revision: https://phabricator.haskell.org/D4158 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 9 23:34:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Nov 2017 23:34:54 -0000 Subject: [GHC] #14311: PowerPC: Symbol already defined In-Reply-To: <047.517ec9911119ab317a73da8842dce7f3@haskell.org> References: <047.517ec9911119ab317a73da8842dce7f3@haskell.org> Message-ID: <062.967ae1f6efd37987bbea7d36ae79fd06@haskell.org> #14311: PowerPC: Symbol already defined ----------------------------------------+------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Comment (by Ben Gamari ): In [changeset:"f8e7fece58fa082b8b5a87fb84ffd5d18500d26a/ghc" f8e7fece/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f8e7fece58fa082b8b5a87fb84ffd5d18500d26a" Fix PPC NCG after blockID patch Commit rGHC8b007ab assigns the same label to the first basic block of a proc and to the proc entry point. This violates the PPC 64-bit ELF v. 1.9 and v. 2.0 ABIs and leads to duplicate symbols. This patch fixes duplicate symbols caused by block labels In commit rGHCd7b8da1 an info table label is generated from a block id. Getting the entry label from that info label leads to an undefined symbol because a suffix "_entry" that is not present in the block label. To fix that issue add a new info table label flavour for labels derived from block ids. Converting such a label with toEntryLabel produces the original block label. Fixes #14311 Test Plan: ./validate Reviewers: austin, bgamari, simonmar, erikd, hvr, angerman Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14311 Differential Revision: https://phabricator.haskell.org/D4149 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 03:36:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 03:36:17 -0000 Subject: [GHC] #14391: Make the simplifier independent of the typechecker In-Reply-To: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> References: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> Message-ID: <061.aed991e86fb2ac892f32b23b2d0f87f3@haskell.org> #14391: Make the simplifier independent of the typechecker -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jkiefer): Gotcha. Thank you for the guidance! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 04:51:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 04:51:21 -0000 Subject: [GHC] #8238: Implement unloading of shared libraries In-Reply-To: <047.e2bbc066d014f0f597cdb8b788581350@haskell.org> References: <047.e2bbc066d014f0f597cdb8b788581350@haskell.org> Message-ID: <062.8e9a973187089f992000306a1b45d8c9@haskell.org> #8238: Implement unloading of shared libraries -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8039 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mniip): * cc: mniip (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 05:54:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 05:54:44 -0000 Subject: [GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects In-Reply-To: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> References: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> Message-ID: <064.a0c641c755352e4b46e1923bafb5f129@haskell.org> #14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | 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 angerman): I'll eventually look into the recursive linking part. I've added aggressive name mangling to cabal for macOS a while ago, which help elevate this issue to a certain part. But we will eventually be unable to _always_ stay under the limit. So a temporary work around (unless you really have excessive amounts of dependencies), might be to use a Cabal build from HEAD. I'm not certain how stack handles this and haven't looked into it. You are basically looking for any point after https://github.com/haskell/cabal/pull/4656 was merged. (3da83a0 was merged into haskell/cabal on Aug 22 2017). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 05:55:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 05:55:02 -0000 Subject: [GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects In-Reply-To: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> References: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> Message-ID: <064.672c588b2e893ece1780e6da42db1a4f@haskell.org> #14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: angerman Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | 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 angerman): * cc: angerman (added) * owner: (none) => angerman -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 06:27:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 06:27:55 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.31aa524eb18f39d539c1e687238177bd@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): I'm picking this up now. Any pointers on how to build a sensible benchmark for HasCallstack? Here's what I'm planning to do: * Benchmark small pieces of pure code which calls `error` or `throwIO` or `throwM` where every function where every function in the callstack has/omits the `HasCallstack` constraint. * Benchmark some real-world libraries that involve parsing and IO with/without the `HasCallstack` constraint, eg. opaleye, postgresql- simple, yaml, and aeson. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 07:29:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 07:29:45 -0000 Subject: [GHC] #14447: Add unaligned ByteArray# access primops Message-ID: <046.0a42b39c2bbd29dbc134fbdc71e5a044@haskell.org> #14447: Add unaligned ByteArray# access primops -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 would like unaligned store and unaligned load primops in GHC.Prim. Specifically: for X in {Int,Int16,Int32,Int64,Word,Word16,Word32,Word64,Float,Double,WideChar,Addr,StablePtr} and where X# is the corresponding Int#/Word#/Float#/Double#/Char#/Addr#/StablePtr# type, I'd like the following primitives: {{{#!hs -- | Reads an 'X#', offset in bytes indexXArrayOffBytes# :: ByteArray# -> Int# -> X# -- | Reads an 'X#', offset in bytes readXArrayOffBytes# :: MutableByteArray# s -> Int# -> State# s -> (#State# s, X# #) -- | Writes an 'X#', offset in bytes writeXArrayOffBytes# :: MutableByteArray# s -> Int# -> X# -> State# s -> State# s }}} Note that the indexXOffAddr# family of functions already provides unaligned loads and similarly writeXOffAddr# provides unaligned stores, so GHC's code generator must handle these already. For example, we could use these to provide unaligned loads for pinned ByteArray#s: {{{#!hs indexWord16ArrayOffBytes# :: ByteArray# -> Int# -> Word# indexWord16ArrayOffBytes# arr offset = indexWord16OffAddr# (byteArrayContents# arr `plusAddr#` offset) 0# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 07:48:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 07:48:15 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.ccae58f9b7df9dc70e5adef079ecc6dc@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): Does this seem like a sensible benchmark for a pure function that throws an Exception: https://github.com/vacationlabs/hascallstack- benchmarks/blob/f055b16db7bf42e069daf25e126bd04a3c8b65bc/app/Main.hs Here are the numbers, which seem to be suggesting a 6-7x perf penalty for using `HasCallstack`, which seems to be getting worse as the depth of the callstack increases: * factorial/20: 4x penalty * factorial/30: 4.8x penalty * factorial/50: 5.9x penalty * factorial/100: 6.9x penalty * factorial/200: 7.7x penalty * factorial/300: 7.8x penalty Can someone confirm this pattern on their machine as well? {{{ benchmarking factorial/regular/20 time 1.757 μs (1.734 μs .. 1.782 μs) 0.999 R² (0.998 R² .. 1.000 R²) mean 1.732 μs (1.722 μs .. 1.753 μs) std dev 41.67 ns (26.25 ns .. 72.27 ns) variance introduced by outliers: 30% (moderately inflated) benchmarking factorial/callstack/20 time 7.080 μs (7.041 μs .. 7.138 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 7.087 μs (7.058 μs .. 7.135 μs) std dev 128.1 ns (88.70 ns .. 183.6 ns) variance introduced by outliers: 17% (moderately inflated) benchmarking factorial/regular/30 time 2.142 μs (2.129 μs .. 2.161 μs) 0.999 R² (0.998 R² .. 1.000 R²) mean 2.155 μs (2.140 μs .. 2.192 μs) std dev 76.73 ns (47.29 ns .. 132.5 ns) variance introduced by outliers: 48% (moderately inflated) benchmarking factorial/callstack/30 time 10.42 μs (10.34 μs .. 10.53 μs) 0.999 R² (0.998 R² .. 1.000 R²) mean 10.65 μs (10.53 μs .. 10.84 μs) std dev 527.4 ns (362.1 ns .. 827.1 ns) variance introduced by outliers: 60% (severely inflated) benchmarking factorial/regular/50 time 2.962 μs (2.933 μs .. 3.007 μs) 0.998 R² (0.997 R² .. 1.000 R²) mean 2.972 μs (2.947 μs .. 3.021 μs) std dev 119.0 ns (80.88 ns .. 181.1 ns) variance introduced by outliers: 53% (severely inflated) benchmarking factorial/callstack/50 time 17.56 μs (17.26 μs .. 18.13 μs) 0.993 R² (0.979 R² .. 0.999 R²) mean 17.62 μs (17.34 μs .. 18.34 μs) std dev 1.365 μs (588.7 ns .. 2.620 μs) variance introduced by outliers: 77% (severely inflated) benchmarking factorial/regular/100 time 4.920 μs (4.883 μs .. 4.973 μs) 0.999 R² (0.998 R² .. 1.000 R²) mean 4.969 μs (4.915 μs .. 5.037 μs) std dev 200.2 ns (144.0 ns .. 264.3 ns) variance introduced by outliers: 52% (severely inflated) benchmarking factorial/callstack/100 time 33.78 μs (33.63 μs .. 33.99 μs) 0.999 R² (0.999 R² .. 1.000 R²) mean 34.36 μs (34.04 μs .. 34.98 μs) std dev 1.493 μs (1.015 μs .. 2.390 μs) variance introduced by outliers: 50% (moderately inflated) benchmarking factorial/regular/200 time 9.002 μs (8.921 μs .. 9.131 μs) 0.999 R² (0.998 R² .. 1.000 R²) mean 9.132 μs (9.052 μs .. 9.229 μs) std dev 299.3 ns (238.2 ns .. 375.3 ns) variance introduced by outliers: 39% (moderately inflated) benchmarking factorial/callstack/200 time 69.26 μs (67.10 μs .. 71.77 μs) 0.995 R² (0.992 R² .. 1.000 R²) mean 68.59 μs (67.86 μs .. 69.60 μs) std dev 2.830 μs (1.919 μs .. 3.858 μs) variance introduced by outliers: 44% (moderately inflated) benchmarking factorial/regular/300 time 12.93 μs (12.90 μs .. 12.97 μs) 0.999 R² (0.999 R² .. 1.000 R²) mean 13.27 μs (13.11 μs .. 13.51 μs) std dev 597.3 ns (422.6 ns .. 842.9 ns) variance introduced by outliers: 54% (severely inflated) benchmarking factorial/callstack/300 time 101.2 μs (100.7 μs .. 101.7 μs) 0.999 R² (0.999 R² .. 1.000 R²) mean 103.9 μs (102.5 μs .. 105.9 μs) std dev 5.361 μs (3.981 μs .. 6.618 μs) variance introduced by outliers: 54% (severely inflated) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 09:02:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 09:02:34 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.0bd17b4ec7e26e1d0b339196423fd7ce@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): Does anyone know if this kind of perf penalty is a fact-of-life with other languages as well, except other languages don't have an optional callstack, so no one even knows? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 09:14:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 09:14:13 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.ea94166ee4941e589f28c37b45f2c096@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 simonpj): factorial is a very particular kind of program. I really doubt that a factor of 7 is typical. And I'd want to dig a bit more into what is happening here. Factorial 300 builds a stack of depth 300 -- but it also computes some extremly large `Integers`. As the size goes up I'd expect eventually 99% of the time to be spent in GMP. (This is another reason why this particular benchmark might be considered misleading.) So where is that increasing factor coming from? I'm not denying it's there; but sometimes these corner cases show up some stupid infelicity in GHC that is easily fixed. There are lots of programs in `nofib` that are a bit less unrealistic than factorial. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 09:21:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 09:21:58 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.79ffebc083fdd29b5f2ebc151c92deda@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): > There are lots of programs in nofib that are a bit less unrealistic than factorial. Are you referring to https://github.com/ghc/nofib/tree/master/real ? Which program from that directly would you suggest for the HasCallStack benchmark? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 09:26:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 09:26:30 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.0a95bb6e7177ffccce0c5efb492d2ee7@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 simonpj): Yes, but there are also the `imaginary` and `spectral` suites. See [https://github.com/ghc/nofib] There's a [https://www.semanticscholar.org/paper/The-nofib-Benchmark- Suite-of-Haskell-Programs-Partain/60d73856a1b51913e9179377356bdd63e270a199 paper about nofib] I don't know which is most suitable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 09:43:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 09:43:19 -0000 Subject: [GHC] #14447: Add unaligned ByteArray# access primops In-Reply-To: <046.0a42b39c2bbd29dbc134fbdc71e5a044@haskell.org> References: <046.0a42b39c2bbd29dbc134fbdc71e5a044@haskell.org> Message-ID: <061.8d729ffa5144f995409d57551e41e6d3@haskell.org> #14447: Add unaligned ByteArray# access primops -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4442 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => duplicate * related: => #4442 Comment: This is a long-standing feature request and I consider this a duplicate of #4442 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 09:43:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 09:43:52 -0000 Subject: [GHC] #4442: Add unaligned version of indexWordArray# In-Reply-To: <044.4c85d11a3d9c22b5e6021cb85ad43106@haskell.org> References: <044.4c85d11a3d9c22b5e6021cb85ad43106@haskell.org> Message-ID: <059.9f7b3cbda2fb49c74d179d6264192fdd@haskell.org> #4442: Add unaligned version of indexWordArray# -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): I just marked #14447 as a duplicate of this one -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 09:44:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 09:44:02 -0000 Subject: [GHC] #4442: Add unaligned version of indexWordArray# In-Reply-To: <044.4c85d11a3d9c22b5e6021cb85ad43106@haskell.org> References: <044.4c85d11a3d9c22b5e6021cb85ad43106@haskell.org> Message-ID: <059.30119dfd4b8edaee30f2557f17c70f80@haskell.org> #4442: Add unaligned version of indexWordArray# -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14447 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * related: => #14447 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 10:14:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 10:14:16 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.595623cb145f39fbacb741efb7a93be5@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): Here are some benchmarks for postgresql-simple, a project which is doing significant real-world IO (which is where most errors occur, in my experience): **No Callstack -- Benchmarking a query with/without error** {{{ benchmarking complicatedQuery/without error time 172.3 μs (169.0 μs .. 175.2 μs) 0.985 R² (0.971 R² .. 0.993 R²) mean 224.5 μs (203.3 μs .. 271.1 μs) std dev 110.9 μs (58.97 μs .. 200.8 μs) variance introduced by outliers: 99% (severely inflated) benchmarking complicatedQuery/with error time 171.4 μs (169.6 μs .. 173.5 μs) 0.996 R² (0.992 R² .. 0.999 R²) mean 174.4 μs (171.3 μs .. 179.8 μs) std dev 14.00 μs (8.934 μs .. 19.24 μs) variance introduced by outliers: 72% (severely inflated) }}} **HasCallStack -- Benchmarking same query but with [https://github.com/vacationlabs/postgresql- simple/commit/774d3eaa259c217ada3918e5c29f3dab792af38c: HasCallStack applied on almost every function of the library]** {{{ benchmarking complicatedQuery/without error time 177.9 μs (176.3 μs .. 180.6 μs) 0.996 R² (0.992 R² .. 0.998 R²) mean 186.8 μs (182.6 μs .. 192.6 μs) std dev 17.42 μs (13.92 μs .. 21.59 μs) variance introduced by outliers: 78% (severely inflated) benchmarking complicatedQuery/with error time 171.4 μs (168.7 μs .. 175.6 μs) 0.991 R² (0.981 R² .. 0.997 R²) mean 175.3 μs (171.4 μs .. 182.1 μs) std dev 17.27 μs (11.45 μs .. 25.30 μs) variance introduced by outliers: 80% (severely inflated) }}} The difference in perf is coming across as almost noise. **Is this an acceptable benchmark for measuring real-world impact of enabling HasCallstack for IO-centric functions? Does this strengthen the case for implementing this flag?** -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 10:30:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 10:30:15 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.671c7b30a0e05d9b45abb5f288071997@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications 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 dredozubov): It seems I created a duplicate ticket #14446 I'm linking it to add my two cents to a plethora of examples provided by @Iceland_jack -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 10:30:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 10:30:16 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.94e2da99af797806c60ab3ae1fd62b91@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): **Question** -- if `error` is not there in the source code, does GHC optimise away `HasCallStack` completely? I'm seeing the same perf numbers for the two functions given below (the call to `throw` has been commented out): {{{ factorialCS :: (HasCallStack) => Integer -> Integer factorialCS 1 = 1 -- factorialCS 3 = throw $ CustomException "Error from CS version" callStack factorialCS n = n * factorialCS (n - 1) factorial :: Integer -> Integer factorial 1 = 1 -- factorial 3 = throw $ CustomException "Error from non-CS version" emptyCallStack factorial n = n * factorial (n - 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 10:32:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 10:32:01 -0000 Subject: [GHC] #14446: Extending TypeApplications to support infix functions In-Reply-To: <049.464ef058942aef80120ed6efe1ff4857@haskell.org> References: <049.464ef058942aef80120ed6efe1ff4857@haskell.org> Message-ID: <064.6efa4397d2b155d5e051e7f419c1c8aa@haskell.org> #14446: Extending TypeApplications to support infix functions -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 dredozubov): * status: new => closed * resolution: => duplicate Comment: Seems like I made a duplicate of #12363, I'm linking this ticket there and closing this one -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 11:19:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 11:19:43 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.175b95a6518b1f838a0885a74f7c55f2@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications 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 AntC): I'm perturbed by the type argument appearing after the infix operator; whereas with a prefixed function the type argument comes first. In {{{ instance Eq a => Eq [a] where ... (x:xs) == (y:ys) = x == @a y && xs == @[a] ys }}} the prefix form would put `@a` before `x` So my brain has to parse that as `x (== @a) y`. Shouldn't it be like this {{{ (x:xs) == (y:ys) = @a x == y && @[a] xs == ys }}} I notice in @dredozubov's #14446, the `@"foo"` comes before the operator. As to whether the syntax becomes less scary from looking through the examples: no, to me it still looks like perl or Teco. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 12:03:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 12:03:08 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.e451f4d538af3860961c5726bfdf2fb2@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): **UPDATE** It seems that GHC is optimising away all callstack related code if `callStack` is not actually being used (which was the case with `postgresql-simple`). Here are the same benchmarks as [https://ghc.haskell.org/trac/ghc/ticket/13360#comment:20: earlier], but with `callStack` [https://github.com/vacationlabs/postgresql- simple/commit/355f0bcefacfaa6dfb808b5bbbb4fa89956650ae: actually being used.] There seems to be a **1.6x perf penalty** in real-world IO-centric code. It seems to be quite a big perf penalty. How do I dig deeper? **HasCallStack, where the callStack is actually being used** {{{ benchmarking complicatedQuery/without error time 289.7 μs (250.6 μs .. 330.3 μs) 0.905 R² (0.850 R² .. 0.961 R²) mean 276.8 μs (263.2 μs .. 293.6 μs) std dev 49.36 μs (34.39 μs .. 70.50 μs) variance introduced by outliers: 92% (severely inflated) benchmarking complicatedQuery/with error time 269.1 μs (242.8 μs .. 294.2 μs) 0.947 R² (0.919 R² .. 0.979 R²) mean 274.3 μs (262.3 μs .. 286.1 μs) std dev 43.09 μs (33.99 μs .. 54.33 μs) variance introduced by outliers: 90% (severely inflated) }}} **Without HasCallStack** {{{ benchmarking complicatedQuery/without error time 183.9 μs (179.6 μs .. 189.9 μs) 0.992 R² (0.987 R² .. 0.997 R²) mean 186.6 μs (183.1 μs .. 193.1 μs) std dev 15.60 μs (11.45 μs .. 20.83 μs) variance introduced by outliers: 74% (severely inflated) benchmarking complicatedQuery/with error time 180.7 μs (176.3 μs .. 187.1 μs) 0.992 R² (0.984 R² .. 0.999 R²) mean 181.9 μs (179.4 μs .. 186.7 μs) std dev 11.55 μs (7.139 μs .. 19.47 μs) variance introduced by outliers: 61% (severely inflated) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 12:25:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 12:25:12 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.d5519dc8d73ec549aa7ad632c0c35349@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 gridaphobe): Thanks for digging in to this! Now that we can see there is an impact for real-world code, I'd suggest stepping back to the simpler examples like the `loop` benchmark I linked earlier, to determine what's causing the overhead. HasCallStack **should** be equivalent to an extra argument that builds up a list of SrcLocs (technically `(String, SrcLoc)` pairs). So my first experiment would probably be to write another benchmark that implements HasCallStack in user code. These two versions should perform the same, do they? If not, maybe GHC is doing something silly when it generates the HasCallStack code. Next I would try shrinking the contents of the user-level CallStack, instead of `(String, SrcLoc)` make it a list of `()`. This should measure the cost of pushing a new item onto the stack. Perhaps that cost is proportional to the size of the item (I wouldn't think so since the item should be a thunk, but it's worth checking). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 13:42:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 13:42:31 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.75adc4f75832420ac45d440f01529146@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): > These two versions should perform the same, do they? They seem to be performing almost the same (benchmarks are called `explicit callstack` below) -- in fact, the explicitly managed callstack is performing slightly worse. > Next I would try shrinking the contents of the user-level CallStack This seems to be the **biggest cost** (benchmarks are called `explicit callstack (mini)` below. In fact, with the "minified contents" the perf- penalty is **~1.2x vis-a-vis ~3-4x** in the regular callstack. [https://github.com/vacationlabs/hascallstack- benchmarks/blob/7e32c2d95f6fd82b0afbf0436a895f9edf1913e0/app/Main.hs: Benchmark code] {{{ benchmarking recur/no callstack/10 time 837.4 ns (826.7 ns .. 850.3 ns) 0.999 R² (0.998 R² .. 1.000 R²) mean 829.8 ns (824.7 ns .. 838.4 ns) std dev 20.68 ns (11.06 ns .. 33.00 ns) variance introduced by outliers: 33% (moderately inflated) benchmarking recur/HasCallStack/10 time 2.773 μs (2.763 μs .. 2.787 μs) 0.999 R² (0.999 R² .. 1.000 R²) mean 2.797 μs (2.775 μs .. 2.846 μs) std dev 105.8 ns (38.93 ns .. 174.7 ns) variance introduced by outliers: 50% (severely inflated) benchmarking recur/explicit callstack/10 time 4.103 μs (4.086 μs .. 4.131 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 4.147 μs (4.114 μs .. 4.210 μs) std dev 157.9 ns (107.7 ns .. 233.9 ns) variance introduced by outliers: 50% (moderately inflated) benchmarking recur/explicit callstack (mini)/10 time 1.027 μs (1.024 μs .. 1.031 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 1.048 μs (1.037 μs .. 1.068 μs) std dev 52.87 ns (35.62 ns .. 76.73 ns) variance introduced by outliers: 67% (severely inflated) benchmarking recur/no callstack/100 time 8.290 μs (7.961 μs .. 8.558 μs) 0.995 R² (0.993 R² .. 1.000 R²) mean 8.061 μs (7.992 μs .. 8.224 μs) std dev 312.9 ns (154.9 ns .. 482.3 ns) variance introduced by outliers: 48% (moderately inflated) benchmarking recur/HasCallStack/100 time 32.06 μs (31.89 μs .. 32.23 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 32.05 μs (31.96 μs .. 32.17 μs) std dev 368.3 ns (299.5 ns .. 449.9 ns) benchmarking recur/explicit callstack/100 time 48.52 μs (47.12 μs .. 49.92 μs) 0.997 R² (0.995 R² .. 1.000 R²) mean 47.70 μs (47.39 μs .. 48.28 μs) std dev 1.334 μs (750.2 ns .. 2.156 μs) variance introduced by outliers: 28% (moderately inflated) benchmarking recur/explicit callstack (mini)/100 time 9.225 μs (9.111 μs .. 9.423 μs) 0.998 R² (0.996 R² .. 1.000 R²) mean 9.188 μs (9.121 μs .. 9.306 μs) std dev 291.6 ns (160.9 ns .. 459.9 ns) variance introduced by outliers: 38% (moderately inflated) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 14:16:31 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 14:16:31 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.9cd30893c6186c5a0ad850e215bd03bc@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 gridaphobe): Interesting! So it appears that the overhead is coming from the contents of each entry in the call stack. I'm a bit surprised by this, the `String` and `SrcLoc` should both be floated out and shared between calls (like you did manually with `spuriousSrcLoc`). I wouldn't expect that to cause such an overhead. It would be good to isolate which part of the stack entries is causing the overhead, e.g. Is it the `String`s? (we could use `Addr#` like GHC does for compiler-generated errors) Is the number of fields in a `SrcLoc` causing one of GHC's size heuristics to act strangely? etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 14:36:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 14:36:15 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.d903361160664c2cc889fbb38fddf142@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): **I think we are aren't approaching this pragmatically.** The 3.4x penalty, reported above, occurs only when every single computation throws an error and the error/callstack is forced (usually by printing it to a log-file). **However** in real life only a certain percentage of computations fail, and most of the times the callstacks aren't evaluated completely. (I tried a version where `e deepseq` wasn't being called and every version of the code had the same perf. Here are some benchmarks where **only 20% computations fail**. [https://github.com/vacationlabs/hascallstack- benchmarks/blob/84ab56c63eb96208c5193a187b431251037a2ce8/app/Main.hs: code is here] The perf penalty is now **~1.2x** for the `HasCallStack` version. I think there is still some opportunity to optimise the stack entries, but the perf penalty in real-world scenarios is not as alarming as I had earlier reported. **This is going to be 'Exhibit A' whenever I need to cite advantages of lazy evaluation** {{{ benchmarking recur/no callstack/1000 time 1.720 ms (1.648 ms .. 1.776 ms) 0.992 R² (0.987 R² .. 0.996 R²) mean 1.668 ms (1.638 ms .. 1.703 ms) std dev 117.6 μs (97.03 μs .. 144.4 μs) variance introduced by outliers: 53% (severely inflated) benchmarking recur/HasCallStack/1000 time 1.700 ms (1.660 ms .. 1.742 ms) 0.994 R² (0.990 R² .. 0.997 R²) mean 1.725 ms (1.695 ms .. 1.762 ms) std dev 117.1 μs (95.96 μs .. 150.7 μs) variance introduced by outliers: 52% (severely inflated) benchmarking recur/explicit callstack/1000 time 1.740 ms (1.701 ms .. 1.782 ms) 0.994 R² (0.991 R² .. 0.997 R²) mean 1.746 ms (1.710 ms .. 1.779 ms) std dev 126.3 μs (101.9 μs .. 158.5 μs) variance introduced by outliers: 53% (severely inflated) benchmarking recur/explicit callstack (mini)/1000 time 1.694 ms (1.639 ms .. 1.758 ms) 0.988 R² (0.976 R² .. 0.995 R²) mean 1.735 ms (1.701 ms .. 1.783 ms) std dev 135.1 μs (102.7 μs .. 180.1 μs) variance introduced by outliers: 58% (severely inflated) benchmarking recur/no callstack/10000 time 16.70 ms (14.62 ms .. 18.45 ms) 0.941 R² (0.888 R² .. 0.975 R²) mean 19.34 ms (18.32 ms .. 20.57 ms) std dev 2.575 ms (1.965 ms .. 3.431 ms) variance introduced by outliers: 62% (severely inflated) benchmarking recur/HasCallStack/10000 time 20.03 ms (18.44 ms .. 21.43 ms) 0.955 R² (0.911 R² .. 0.979 R²) mean 19.07 ms (17.62 ms .. 20.33 ms) std dev 3.299 ms (2.438 ms .. 4.141 ms) variance introduced by outliers: 71% (severely inflated) benchmarking recur/explicit callstack/10000 time 21.81 ms (20.15 ms .. 22.95 ms) 0.967 R² (0.919 R² .. 0.993 R²) mean 21.22 ms (19.91 ms .. 22.07 ms) std dev 2.337 ms (1.799 ms .. 3.171 ms) variance introduced by outliers: 51% (severely inflated) benchmarking recur/explicit callstack (mini)/10000 time 18.23 ms (15.22 ms .. 20.59 ms) 0.904 R² (0.825 R² .. 0.960 R²) mean 20.31 ms (18.68 ms .. 21.64 ms) std dev 3.227 ms (2.640 ms .. 3.903 ms) variance introduced by outliers: 71% (severely inflated) benchmarking recur/no callstack/100000 time 199.8 ms (119.6 ms .. 283.6 ms) 0.857 R² (0.493 R² .. 1.000 R²) mean 199.5 ms (152.1 ms .. 232.5 ms) std dev 49.70 ms (37.44 ms .. 59.33 ms) variance introduced by outliers: 65% (severely inflated) benchmarking recur/HasCallStack/100000 time 210.9 ms (166.5 ms .. 262.5 ms) 0.970 R² (0.924 R² .. 1.000 R²) mean 170.5 ms (152.4 ms .. 188.6 ms) std dev 21.57 ms (13.10 ms .. 33.13 ms) variance introduced by outliers: 32% (moderately inflated) benchmarking recur/explicit callstack/100000 time 288.3 ms (229.0 ms .. 398.6 ms) 0.965 R² (0.893 R² .. 1.000 R²) mean 242.8 ms (192.7 ms .. 270.7 ms) std dev 48.74 ms (11.69 ms .. 64.53 ms) variance introduced by outliers: 57% (severely inflated) benchmarking recur/explicit callstack (mini)/100000 time 215.5 ms (73.60 ms .. 322.8 ms) 0.804 R² (0.327 R² .. 1.000 R²) mean 212.8 ms (157.4 ms .. 242.9 ms) std dev 50.88 ms (24.98 ms .. 66.53 ms) variance introduced by outliers: 65% (severely inflated) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 15:22:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 15:22:34 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.98f94c52ce04632e96074176de837e43@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): Here are the benchmarks of postgresql-simple with only 20% queries resulting in an error. There's **no perceptible difference in perf.** **With HasCallStack** {{{ benchmarking complicatedQuery/with error time 186.4 μs (178.2 μs .. 195.3 μs) 0.989 R² (0.986 R² .. 0.996 R²) mean 198.0 μs (190.5 μs .. 207.8 μs) std dev 29.62 μs (22.83 μs .. 37.34 μs) variance introduced by outliers: 90% (severely inflated) }}} **Without HasCallStack** {{{ benchmarking complicatedQuery/with error time 187.3 μs (180.5 μs .. 197.0 μs) 0.986 R² (0.970 R² .. 0.999 R²) mean 184.4 μs (181.3 μs .. 189.8 μs) std dev 14.19 μs (7.153 μs .. 23.78 μs) variance introduced by outliers: 70% (severely inflated) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 16:01:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 16:01:20 -0000 Subject: [GHC] #14448: CircleCI can't build on OS X Message-ID: <046.1aebf3557dc17190496a1d6ce081057b@haskell.org> #14448: CircleCI can't build on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 8.2.1 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 mentioned in [[https://github.com/ghc/ghc/pull/83]] CircleCI seems to have trouble with OS X builds. They invariably end in one of a few ways, * it hangs * it is "cancelled" with CircleCI issuing the vague warning that there was "an issue while running this container" Fuuzetsu has raised the issue with CircleCI support. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 18:25:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 18:25:22 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.314d9ff8a16bab5ecfdaa03bd618ff4f@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 gridaphobe): Aha, I didn't realize that your benchmarks were always throwing the error. This makes a lot more sense now, using `HasCallStack` ought to be fairly cheap in the common case were the error does not occur. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 19:53:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 19:53:18 -0000 Subject: [GHC] #14448: CircleCI can't build on OS X In-Reply-To: <046.1aebf3557dc17190496a1d6ce081057b@haskell.org> References: <046.1aebf3557dc17190496a1d6ce081057b@haskell.org> Message-ID: <061.774f373d6ce32a551ff5efe8d3da1912@haskell.org> #14448: CircleCI can't build on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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 bgamari): * owner: (none) => bgamari * component: None => Continuous Integration -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 19:53:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 19:53:43 -0000 Subject: [GHC] #13716: Move CI to Jenkins In-Reply-To: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> References: <046.48e2facaae8e965ca7d5990f8113aa95@haskell.org> Message-ID: <061.8d2155522a15c2cc80c6807988ed1df2@haskell.org> #13716: Move CI to Jenkins -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Continuous | Version: 8.0.1 Integration | Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13897, 14291 | Blocking: Related Tickets: #11958, #13205 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * component: None => Continuous Integration -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 19:55:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 19:55:15 -0000 Subject: [GHC] #13121: Investigate whether uploading build artifacts from harbormaster would be usful In-Reply-To: <049.7c32dc32e9d5ea84423377cf9fb4523c@haskell.org> References: <049.7c32dc32e9d5ea84423377cf9fb4523c@haskell.org> Message-ID: <064.d5ea17c37a6cf62488b0146eb31bc9da@haskell.org> #13121: Investigate whether uploading build artifacts from harbormaster would be usful -------------------------------------+------------------------------------- Reporter: mpickering | Owner: bgamari Type: task | Status: closed Priority: normal | Milestone: Component: Continuous | Version: Integration | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * status: new => closed * component: Compiler => Continuous Integration * resolution: => fixed Comment: We will get this from CircleCI. See wiki:ContinuousIntegration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 19:55:29 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 19:55:29 -0000 Subject: [GHC] #13122: Investigate reporting build errors with harbormaster.sendmessage In-Reply-To: <049.54c13e103fdc94439f44b93c6bb94486@haskell.org> References: <049.54c13e103fdc94439f44b93c6bb94486@haskell.org> Message-ID: <064.b45262a14cbcab4b3cb3b0549ac929af@haskell.org> #13122: Investigate reporting build errors with harbormaster.sendmessage -------------------------------------+------------------------------------- Reporter: mpickering | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 8809 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * component: Compiler => Continuous Integration -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 19:55:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 19:55:40 -0000 Subject: [GHC] #12623: Make Harbormaster less terrible in the face of submodule updates In-Reply-To: <046.6ed234b0aab5561063eed563f1a09702@haskell.org> References: <046.6ed234b0aab5561063eed563f1a09702@haskell.org> Message-ID: <061.720722bc6f3600ec4396e8d48248d6f2@haskell.org> #12623: Make Harbormaster less terrible in the face of submodule updates -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: closed Priority: highest | Milestone: Component: Continuous | Version: 8.0.1 Integration | 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): * component: Build System => Continuous Integration -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 10 20:06:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Nov 2017 20:06:52 -0000 Subject: [GHC] #14449: Type variables allowed to unify in a partial type signature (PartialTypeSignatures) Message-ID: <047.c826e6c9d1aac2c5c605f0d32075e17d@haskell.org> #14449: Type variables allowed to unify in a partial type signature (PartialTypeSignatures) -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | 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: -------------------------------------+------------------------------------- During a discussion today, Richard discovered the following bug: The function `f` is accepted in GHC 8.2.1 (and HEAD too): {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} f :: a -> b -> _ f x y = [x, y] }}} with the warning: {{{ Bug.hs:3:16: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘[a]’ Where: ‘a’ is a rigid type variable bound by the inferred type of f :: a -> a -> [a] at Bug.hs:4:1-13 • In the type signature: f :: a -> b -> _ | 3 | f :: a -> b -> _ | ^ Ok, 1 module loaded. }}} This is a regression compared to 8.0.1, where the following error is produced (rightly): {{{ Bug.hs:4:12: error: • Couldn't match expected type ‘a’ with actual type ‘b’ ‘b’ is a rigid type variable bound by the inferred type of f :: a -> b -> [a] at Bug.hs:3:6 ‘a’ is a rigid type variable bound by the inferred type of f :: a -> b -> [a] at Bug.hs:3:6 • In the expression: y In the expression: [x, y] In an equation for ‘f’: f x y = [x, y] • Relevant bindings include y :: b (bound at Bug.hs:4:5) x :: a (bound at Bug.hs:4:3) f :: a -> b -> [a] (bound at Bug.hs:4:1) Failed, modules loaded: none. }}} Note that the inferred type of `f` is still correct: `f :: a -> a -> a`, but the type variables `a` and `b` are allowed to unify during inference, and they shouldn't be. If I understood correctly, this implies that when inferring the type of functions with partial type signatures, the type variables are (wrongly) treated as `SigTv`s, instead of skolem constants. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 04:07:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 04:07:40 -0000 Subject: [GHC] #9642: LANGUAGE pragma synonyms In-Reply-To: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> References: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> Message-ID: <061.558144b2c9b6895abdde0dbd979a0d31@haskell.org> #9642: LANGUAGE pragma synonyms -------------------------------------+------------------------------------- Reporter: dreixel | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Just a data point: Now that cabal 2 supports multiple library sections, relegating this to `extensions` is even less of a viable alternative. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 04:31:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 04:31:33 -0000 Subject: [GHC] #9642: LANGUAGE pragma synonyms In-Reply-To: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> References: <046.0838efce69e97f2820e750fa3f6155e7@haskell.org> Message-ID: <061.c8254b5dcdb304325cf9eb4fe2149df1@haskell.org> #9642: LANGUAGE pragma synonyms -------------------------------------+------------------------------------- Reporter: dreixel | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Ed, I am not sure I understand your statement. It is less viable to have `extensions` on the top-level cabal file level? Less viable as a statement within a `library` stanza? Less viable anywhere in a `cabal` file? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 06:59:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 06:59:00 -0000 Subject: [GHC] #14450: GHCi spins forever Message-ID: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> #14450: GHCi spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: TypeInType, | Operating System: Unknown/Multiple PolyKinds | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code compiles just fine (8.3.20170920) {{{#!hs {-# Language KindSignatures, TypeOperators, PolyKinds, TypeOperators, ConstraintKinds, TypeFamilies, DataKinds, TypeInType, GADTs, AllowAmbiguousTypes, InstanceSigs #-} import Data.Kind data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type type Cat ob = ob -> ob -> Type type SameKind (a :: k) (b :: k) = (() :: Constraint) type family Apply (f :: a ~> b) (x :: a) :: b where Apply IddSym0 x = Idd x class Varpi (f :: i ~> j) where type Dom (f :: i ~> j) :: Cat i type Cod (f :: i ~> j) :: Cat j varpa :: Dom f a a' -> Cod f (Apply f a) (Apply f a') type family Idd (a::k) :: k where Idd (a::k) = a data IddSym0 :: k ~> k where IddSym0KindInference :: IddSym0 l instance Varpi (IddSym0 :: Type ~> Type) where type Dom (IddSym0 :: Type ~> Type) = (->) type Cod (IddSym0 :: Type ~> Type) = (->) varpa :: (a -> a') -> (a -> a') varpa = id }}} But if you change the final instance to {{{#!hs instance Varpi (IddSym0 :: k ~> k) where type Dom (IddSym0 :: Type ~> Type) = (->) }}} it sends GHC for a spin. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 07:27:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 07:27:11 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.6b7f8aa4e994541a8d1da5494fa2cc27@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): So, how do we take it forward from here? Is it possible to have HasCallStack automatically for functions in IO and/or above a certain cost threshold? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 07:43:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 07:43:37 -0000 Subject: [GHC] #14451: Type synonym of type family causes error, error jumps to (fairly) unrelated source location Message-ID: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> #14451: Type synonym of type family causes error, error jumps to (fairly) unrelated source location -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- {{{#!hs {-# Language KindSignatures, TypeOperators, PolyKinds, TypeOperators, ConstraintKinds, TypeFamilies, DataKinds, TypeInType, GADTs, AllowAmbiguousTypes, InstanceSigs, RankNTypes, UndecidableInstances #-} import Data.Kind data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type type Cat ob = ob -> ob -> Type type family Apply (f :: a ~> b) (x :: a) :: b where Apply (CompSym2 f g) a = Comp f g a data CompSym2 :: (b ~> c) -> (a ~> b) -> (a ~> c) type a·b = Apply a b class Varpi (f :: i ~> j) where type Dom (f :: i ~> j) :: Cat i type Cod (f :: i ~> j) :: Cat j varpa :: Dom f a a' -> Cod f (f·a) (f·a') type family Comp (f::k1 ~> k) (g::k2 ~> k1) (a::k2) :: k where Comp f g a = f · (Apply g a) }}} This compiles, but if I replace the final line by {{{#!hs Comp f g a = f · (g · a) }}} oddly enough I get an error message about the method `varpa`! Seemingly unrelated apart from using `(·)`: {{{ $ ghci2 hs/093-bug.hs GHCi, version 8.3.20170920: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/093-bug.hs, interpreted ) hs/093-bug.hs:23:33: error: • Expected kind ‘i ~> i’, but ‘f’ has kind ‘i ~> j’ • In the first argument of ‘(·)’, namely ‘f’ In the second argument of ‘Cod’, namely ‘(f · a)’ In the type signature: varpa :: Dom f a a' -> Cod f (f · a) (f · a') | 23 | varpa :: Dom f a a' -> Cod f (f·a) (f·a') | ^ Failed, 0 modules loaded. Prelude> }}} NOW — let's randomly remove both lines that mention `CompSym2` and it mysteriously works, again! `Apply` and `(·)` seem to be equal up to variable names, I can't spot why {{{ >> :set -fprint-explicit-foralls >> :set -fprint-explicit-kinds >> :set -fprint-explicit-coercions >> >> :kind Apply Apply :: forall {a} {b}. (a ~> b) -> a -> b >> :kind (·) (·) :: forall {a} {k}. (a ~> k) -> a -> k }}} but it works if I define `(·)` as a type family rather than a synonym: {{{#!hs type family (f::a ~> b) · (x::a) :: b where f · x = Apply f x }}} so it's some difference between synonyms and TFs, but is it intentional? It's certainly odd how the error messages jumped the `varpa` method when we actually modified `Comp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 10:55:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 10:55:25 -0000 Subject: [GHC] #14442: InstanceSigs fails In-Reply-To: <051.92c083a904342cf57cdbf67ba298e591@haskell.org> References: <051.92c083a904342cf57cdbf67ba298e591@haskell.org> Message-ID: <066.ee2d4b54d1de3a20fb2fcf0ca7d1d6f7@haskell.org> #14442: InstanceSigs fails -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: InstanceSigs 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 RyanGlScott): * status: new => infoneeded Comment: Awaiting feedback from Iceland_jack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 11:38:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 11:38:05 -0000 Subject: [GHC] #14398: Fail to install haskell platform on Windows In-Reply-To: <045.d86ee14cadb946edd5536f02e4b96185@haskell.org> References: <045.d86ee14cadb946edd5536f02e4b96185@haskell.org> Message-ID: <060.ac261c3ca7861a4e59e315582e980405@haskell.org> #14398: Fail to install haskell platform on Windows -------------------------------------+------------------------------------- Reporter: KAAAsS | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #14168 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by KAAAsS): Replying to [comment:4 Phyx-]: > Thanks for 8.2 won't work with the monitor, so the output won't be very useful. I'll have to make a special build of 8.2 for you to check. I'll do that today. > > I am however curious as to why the 8.4 build works... can you still attach a log the traces for that one? It should contain the paths i'm after. Capture file of version 8.3.20171021: https://1drv.ms/u/s !AsbnyYMkwdNRjFqeKwZHs-1BsNwd Hope it'll be useful. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 12:24:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 12:24:42 -0000 Subject: [GHC] #14338: Simplifier fails with "Simplifier ticks exhausted" In-Reply-To: <049.819ef8e60a65cb9f3e29afb8f69166a7@haskell.org> References: <049.819ef8e60a65cb9f3e29afb8f69166a7@haskell.org> Message-ID: <064.b56830aeb27d5752bc1d1faccf600bef@haskell.org> #14338: Simplifier fails with "Simplifier ticks exhausted" -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dredozubov): It seems like you forgot to commit src/Runner.hs, there's a src/Runner.hs, but it fails to build with {{{ src/Runner.hs:76:4: error: parse error on input ‘,’ | 76 | , PayloadX | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 12:49:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 12:49:44 -0000 Subject: [GHC] #2431: Allow empty case analysis In-Reply-To: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@haskell.org> References: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@haskell.org> Message-ID: <063.17e6ef19fe8ddfe3247823d004e40db9@haskell.org> #2431: Allow empty case analysis -----------------------------+--------------------------------------------- Reporter: | Owner: (none) RalfHinze | Type: feature | Status: closed request | Priority: low | Milestone: ⊥ Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: empty case analysis Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Type of failure: | Test Case: deSugar/should_compile/T2431 None/Unknown | Blocked By: | Blocking: Related Tickets: | -----------------------------+--------------------------------------------- Changes (by Smartmiltoys): * Attachment "bilets-2018-1.jpg" added. annabelle dollhouses find by [http://smartmiltoys.com/kidkraft-dollhouse /kidkraft-annabelle-dollhouse-65079/ click] this link -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 12:50:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 12:50:27 -0000 Subject: [GHC] #14432: Outdated comment in GHC.Real In-Reply-To: <047.5338823393ca6b66c7faac41f6269e57@haskell.org> References: <047.5338823393ca6b66c7faac41f6269e57@haskell.org> Message-ID: <062.2baa03ee21caa5c58f3de21db40bba71@haskell.org> #14432: Outdated comment in GHC.Real -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: Bodigrim Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 8.2.1 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): Phab:D4171 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Bodigrim): * status: patch => closed * differential: D4171 => Phab:D4171 * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 12:51:48 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 12:51:48 -0000 Subject: [GHC] #14439: Remove redundant subtraction in (^) and stimes In-Reply-To: <047.009e2be896b30621f9e70dd019b082b1@haskell.org> References: <047.009e2be896b30621f9e70dd019b082b1@haskell.org> Message-ID: <062.206c526704e36334acb11f3515584bb2@haskell.org> #14439: Remove redundant subtraction in (^) and stimes -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 8.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): Phab:D4173 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Bodigrim): * status: new => patch * differential: => Phab:D4173 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 13:50:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 13:50:59 -0000 Subject: [GHC] #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. In-Reply-To: <044.8846313dfa837f257582237983583132@haskell.org> References: <044.8846313dfa837f257582237983583132@haskell.org> Message-ID: <059.62ef95f97bf5f8242a27e60860318626@haskell.org> #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. ---------------------------------+-------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 15:54:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 15:54:30 -0000 Subject: [GHC] #450: "class A where a :: A -> Int" panics GHC 6.4 In-Reply-To: <048.f61eb96b0caaadbce64d75c34a1b4418@haskell.org> References: <048.f61eb96b0caaadbce64d75c34a1b4418@haskell.org> Message-ID: <063.94ecab959d6b15c30ff58223c1ba5381@haskell.org> #450: "class A where a :: A -> Int" panics GHC 6.4 --------------------------------+-------------------- Reporter: carlossch | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: None Resolution: Duplicate | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Changes (by Ben Gamari ): * failure: => None/Unknown Comment: In [changeset:"5229c43ccf77bcbffeced01dccb27398d017fa34/ghc" 5229c43c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5229c43ccf77bcbffeced01dccb27398d017fa34" Squashed 'hadrian/' changes from 438dc576e7..5ebb69ae1e 5ebb69ae1e Drop GccLtXX flags, require GCC > 4.7 and up (#450) git-subtree-dir: hadrian git-subtree-split: 5ebb69ae1eb063f25c59383bffb3b5449015c6f9 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 16:30:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 16:30:13 -0000 Subject: [GHC] #14452: `-optc-O3` getting shadowed by automatically injected -O flags Message-ID: <042.e68200604de67ef001a98aff36406689@haskell.org> #14452: `-optc-O3` getting shadowed by automatically injected -O flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 example: {{{#!hs {-# LANGUAGE CApiFFI #-} {-# OPTIONS_GHC -optc-O3 #-} module M where foreign import capi unsafe "stdlib.h exit" c_exit :: Int -> IO () }}} However, the `-optc-O3` flag has no effect, unless `ghc` is called without any `-O` flags, or with `-O0`. Here's the resulting C compiler invocations for different `-O` flags: {{{ $ ghc -fforce-recomp -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14023_0/ghc_2.c -o /tmp/ghc14023_0/ghc_3.s -Wimplicit -S -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} {{{ $ ghc -fforce-recomp -O0 -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14045_0/ghc_2.c -o /tmp/ghc14045_0/ghc_3.s -Wimplicit -S -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} {{{ $ ghc -fforce-recomp -O1 -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14073_0/ghc_2.c -o /tmp/ghc14073_0/ghc_3.s -Wimplicit -S -O -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} {{{ $ ghc -fforce-recomp -O2 -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14093_0/ghc_2.c -o /tmp/ghc14093_0/ghc_3.s -Wimplicit -S -O2 -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} {{{ $ ghc -fforce-recomp -O3 -v -c m.hs |& grep O3 gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -O3 -x c /tmp/ghc14119_0/ghc_2.c -o /tmp/ghc14119_0/ghc_3.s -Wimplicit -S -O2 -include /opt/ghc/8.2.1/lib/ghc-8.2.1/include/ghcversion.h -I. -I/opt/ghc/8.2.1/lib/ghc-8.2.1/base-4.10.0.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/integer-gmp-1.0.1.0/include -I/opt/ghc/8.2.1/lib/ghc-8.2.1/include }}} To summarise, here's the resulting effective `-O`-level passed to `gcc`: ||= GHC invocation =||= GCC invocation =||= Effective C `-O`-level =|| || `ghc` || `gcc -O3` || `-O3` || || `ghc -O0` || `gcc -O3` || `-O3` || || `ghc -O1` || `gcc -O3 -O1` || `-O1` || || `ghc -O2` || `gcc -O3 -O2` || `-O2` || || `ghc -O3` || `gcc -O3 -O2` || `-O2` || Consequently, the only way to have C code compiled with `-O3` is to force GHC into `-O0` mode; this is obviously not ideal, as it easily kills any benefit you'd gain from passing `-O3` to the C compiler... ;-) I see a few alternatives on how to resolve this: 1. Have GHC recognise `-optc-O[0-9]` and suppress automatically injecting any `-O` of its own 2. Have GHC inject its automatic `-O`-flags before user-provided `-optc` flags 3. Have GHC inject `-optc` flags as late as possible on the C compiler command-line 4. Implement a new variant of the `-optc` flag which injects its flags as late as possible on the C compiler command-line -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 16:41:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 16:41:45 -0000 Subject: [GHC] #14453: CircleCI builds on Linux spuriously fail Message-ID: <046.d9824501282d699cb7ca548d13cf5306@haskell.org> #14453: CircleCI builds on Linux spuriously fail -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Continuous | Version: 8.2.1 Integration | 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, for instance, [[https://circleci.com/api/v1.1/project/github/ghc/ghc/256/output/107/0?file=true|build #256]]. This build seemed to be chugging along quite nicely when at minute 30 it failed with, {{{ "inplace/bin/ghc-stage1" -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -eventlog -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit- id ghc-8.3 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id base-4.11.0.0 -package-id deepseq-1.4.3.0 -package-id directory-1.3.1.5 -package-id process-1.6.1.0 -package-id bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 -package-id filepath-1.4.1.2 -package-id template-haskell-2.13.0.0 -package-id hpc-0.6.0.3 -package-id transformers-0.5.4.0 -package-id ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3 -package-id unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical- monadfail-instances -Wnoncanonical-monoid-instances -this-unit-id ghc -XHaskell2010 -XNoImplicitPrelude -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O2 -Wcpp-undef -no- user-package-db -rtsopts -Wnoncanonical-monad-instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -c compiler/hsSyn/HsDecls.hs -o compiler/stage2/build/HsDecls.p_o -dyno compiler/stage2/build/HsDecls.dyn_o ... compiler/ghc.mk:447: recipe for target 'compiler/stage2/build/HsDecls.p_o' failed make[1]: *** [compiler/stage2/build/HsDecls.p_o] Killed }}} Why was it killed? No one knows. I suspect it ran out of memory since it appears that there was at least seven other GHC processes running concurrently on a machine with only 4 gigabytes of memory. However, seeing as there's no way to tell whether the OOM killer was invoked it's hard to know for certain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 16:46:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 16:46:54 -0000 Subject: [GHC] #14453: CircleCI builds on Linux spuriously fail In-Reply-To: <046.d9824501282d699cb7ca548d13cf5306@haskell.org> References: <046.d9824501282d699cb7ca548d13cf5306@haskell.org> Message-ID: <061.f9177ffa3917a330f681285bfe86d607@haskell.org> #14453: CircleCI builds on Linux spuriously fail -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Continuous | Version: 8.2.1 Integration | 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 Ben Gamari ): In [changeset:"5f158bc1a7eedf8680f4a1e612ca34daa05e0029/ghc" 5f158bc1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5f158bc1a7eedf8680f4a1e612ca34daa05e0029" circleci: Bump down thread count It appears that our jobs generally run on VMs with 2 vCPUs. Consequently running with 8 jobs will completely oversubscribe the machine. I suspect this is the cause of #14453. Let's bump this down to 3 for now. Ideally we would determine this from the environment. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 17:44:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 17:44:18 -0000 Subject: [GHC] #14450: GHCi spins forever In-Reply-To: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> References: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> Message-ID: <066.7a7c51bb0e72b3e4e9b0b3b6a31157ab@haskell.org> #14450: GHCi spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | PolyKinds 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 RyanGlScott): * priority: normal => high * failure: None/Unknown => Compile-time performance bug * milestone: => 8.4.1 Comment: This is a regression from GHC 8.0.2, which simply gives an error message: {{{ $ /opt/ghc/8.0.2/bin/ghci Bug3.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug3.hs, interpreted ) Bug3.hs:31:12: error: • Expected kind ‘k ~> k’, but ‘IddSym0’ has kind ‘Type ~> Type’ • In the first argument of ‘Dom’, namely ‘(IddSym0 :: Type ~> Type)’ In the type instance declaration for ‘Dom’ In the instance declaration for ‘Varpi (IddSym0 :: k ~> k)’ }}} This bug first appeared in commit b207b536ded40156f9adb168565ca78e1eef2c74 (`Generalize kind of the (->) tycon`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 18:11:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 18:11:52 -0000 Subject: [GHC] #14453: CircleCI builds on Linux spuriously fail In-Reply-To: <046.d9824501282d699cb7ca548d13cf5306@haskell.org> References: <046.d9824501282d699cb7ca548d13cf5306@haskell.org> Message-ID: <061.51c75d79641bf9c6ca3405412847a638@haskell.org> #14453: CircleCI builds on Linux spuriously fail -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Continuous | Version: 8.2.1 Integration | 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: I'm going to assume that was the problem; it seems quite likely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 18:43:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 18:43:00 -0000 Subject: [GHC] #14338: Simplifier fails with "Simplifier ticks exhausted" In-Reply-To: <049.819ef8e60a65cb9f3e29afb8f69166a7@haskell.org> References: <049.819ef8e60a65cb9f3e29afb8f69166a7@haskell.org> Message-ID: <064.be57125c1c4154e9294f8cc71a3e5203@haskell.org> #14338: Simplifier fails with "Simplifier ticks exhausted" -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, fair point: `Runner.hs` is generated by `build.sh`. It is necessary to run `build.sh` once before running `cabal new-build`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 20:21:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 20:21:38 -0000 Subject: [GHC] #14449: Type variables allowed to unify in a partial type signature (PartialTypeSignatures) In-Reply-To: <047.c826e6c9d1aac2c5c605f0d32075e17d@haskell.org> References: <047.c826e6c9d1aac2c5c605f0d32075e17d@haskell.org> Message-ID: <062.110277b6a305749abee6d60c52effaea@haskell.org> #14449: Type variables allowed to unify in a partial type signature (PartialTypeSignatures) -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This regression was introduced in commit 15b9bf4ba4ab47e6809bf2b3b36ec16e502aea72 (`Improve typechecking of let- bindings`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 20:24:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 20:24:10 -0000 Subject: [GHC] #14335: Annotations aren't supported with -fexternal-interpreter In-Reply-To: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> References: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> Message-ID: <061.c70f8ba3a21d6f35ff90f878a255b303@haskell.org> #14335: Annotations aren't supported with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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 bgamari): Indeed reproducing this appears to be fairly straightfoward {{{ $ cabal install ghc-typelits-natnormalise $ cat << EOF > hi.hs {-# OPTIONS_GHC -fplugin GHC.TypeLits.Normalise #-} module Hi where EOF $ ghc hi.hs -fforce-recomp -fexternal-interpreter [1 of 1] Compiling Hi ( hi.hs, hi.o ) ghc: this operation requires -fno-external-interpreter }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 20:47:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 20:47:50 -0000 Subject: [GHC] #14335: Annotations aren't supported with -fexternal-interpreter In-Reply-To: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> References: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> Message-ID: <061.9bed6988d5c4f5a471644945ec3061d7@haskell.org> #14335: Annotations aren't supported with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Well, for better or worse I actually can't reproduce this on master. I'll assume this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 21:40:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 21:40:35 -0000 Subject: [GHC] #14450: GHCi spins forever In-Reply-To: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> References: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> Message-ID: <066.78cc2dc39769e995379d17c48b209eeb@haskell.org> #14450: GHCi spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | PolyKinds 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 bgamari): Alright, I can have a look. Sadly `-ddump-tc-trace` doesn't give any hints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 21:44:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 21:44:54 -0000 Subject: [GHC] #11812: Template Haskell can induce non-unique Uniques In-Reply-To: <047.c1baa8985653a0b59eeec1328ee66507@haskell.org> References: <047.c1baa8985653a0b59eeec1328ee66507@haskell.org> Message-ID: <062.558a719ee96efb29ff5a98e36dd7ed76@haskell.org> #11812: Template Haskell can induce non-unique Uniques -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.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 RyanGlScott): Hrm. The panic seems to have been introduced in either commit 77bb09270c70455bbd547470c4e995707d19f37d (`Re-add FunTy (big patch)`) or e368f3265b80aeb337fbac3f6a70ee54ab14edfd (`Major patch to introduce TyConBinder`). (It's hard to say since commit 77bb09270c70455bbd547470c4e995707d19f37d doesn't build, but the commit before that definitely did not exhibit the panic, and commit e368f3265b80aeb337fbac3f6a70ee54ab14edfd does.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 21:57:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 21:57:52 -0000 Subject: [GHC] #14450: GHCi spins forever In-Reply-To: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> References: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> Message-ID: <066.fa387f6dabc2aac9aa8aef8f2e39ac11@haskell.org> #14450: GHCi spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | PolyKinds 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 bgamari): Alright, with `master` `-ddump-tc-trace` is a bit more useful. While looping it appears to dump {{{ Start solver pipeline { work item = [D] _ {1}:: (k_aWv :: *) GHC.Prim.~# (* :: *) (CTyEqCan) inerts = {Equalities: [D] _ {1}:: (k_aWv :: *) GHC.Prim.~# (TYPE q_a20F[tau:1] :: *) (CTyEqCan) [W] hole{a20K} {1}:: (k_aWv :: *) GHC.Prim.~# (* :: *) (CTyEqCan) [W] hole{a20M} {1}:: (k_aWv :: *) GHC.Prim.~# (TYPE q_a20F[tau:1] :: *) (CTyEqCan) Unsolved goals = 2} rest of worklist = WL {Eqs = [WD] hole{a20I} {0}:: (TYPE r_a20G[tau:1] :: *) GHC.Prim.~# (k_aWv :: *) (CNonCanonical)} runStage canonicalization { workitem = [D] _ {1}:: (k_aWv :: *) GHC.Prim.~# (* :: *) (CTyEqCan) can_eq_nc False [D] _ {1}:: (k_aWv :: *) GHC.Prim.~# (* :: *) nominal equality k_aWv k_aWv * * can_eq_nc False [D] _ {1}:: (k_aWv :: *) GHC.Prim.~# (* :: *) nominal equality k_aWv k_aWv * * flatten { FM_FlattenAll k_aWv flatten } k_aWv flatten { FM_FlattenAll * flatten } * can_eq_nc True [D] _ {1}:: (k_aWv :: *) GHC.Prim.~# (* :: *) nominal equality k_aWv k_aWv * * end stage canonicalization } runStage interact with inerts { workitem = [D] _ {1}:: (k_aWv :: *) GHC.Prim.~# (* :: *) (CTyEqCan) Can't solve tyvar equality LHS: k_aWv :: * RHS: * :: * addInertEq { Adding new inert equality: [D] _ {1}:: (k_aWv :: *) GHC.Prim.~# (* :: *) (CTyEqCan) Kick out, tv = k_aWv n-kicked = 1 kicked_out = WL {Eqs = [D] _ {1}:: (k_aWv :: *) GHC.Prim.~# (TYPE q_a20F[tau:1] :: *) (CTyEqCan)} Residual inerts = {Equalities: [W] hole{a20K} {1}:: (k_aWv :: *) GHC.Prim.~# (* :: *) (CTyEqCan) [W] hole{a20M} {1}:: (k_aWv :: *) GHC.Prim.~# (TYPE q_a20F[tau:1] :: *) (CTyEqCan) Unsolved goals = 2} addInertEq } end stage interact with inerts } Step 3424[l:1,d:1] Kept as inert: [D] _ {1}:: (k_aWv :: *) GHC.Prim.~# (* :: *) End solver pipeline (discharged) } ----------------------------- }}} In particular, unless I've misunderstood something, this strikes me as quite odd, {{{ Can't solve tyvar equality LHS: k_aWv :: * RHS: * :: * }}} There's no sign that `k_aWv` is a skolem so why is the solver not simply instantiating it at `*`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 22:12:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 22:12:40 -0000 Subject: [GHC] #14450: GHCi spins forever In-Reply-To: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> References: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> Message-ID: <066.f095cca193f8c0f6c78145f8da2e2f45@haskell.org> #14450: GHCi spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | PolyKinds 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 bgamari): * cc: goldfire (added) Comment: I think I may need to bring Richard in on this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 22:20:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 22:20:29 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.eee19395dc6114c9ee80b63a126288f7@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 bgamari): > So, how do we take it forward from here? Is it possible to have HasCallStack automatically for functions in IO and/or above a certain cost threshold? I think we'll need to define the criterion here a bit more precisely. In particular, it's not clear that doing this in a completely type-driven way makes sense. For instance, what about a function in `MaybeT IO`? Using a size-threshold sounds plausible but feels a bit ad-hoc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 22:20:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 22:20:29 -0000 Subject: [GHC] #9420: Impredicative type instantiation without -XImpredicativeTypes In-Reply-To: <047.6ad1d8a60b0767b72a70d900459f9391@haskell.org> References: <047.6ad1d8a60b0767b72a70d900459f9391@haskell.org> Message-ID: <062.8b01640b7f5ecab3c3b4103ce9c95b56@haskell.org> #9420: Impredicative type instantiation without -XImpredicativeTypes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Keywords: Resolution: fixed | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11319 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * related: => #11319 Comment: This has been fixed since GHC 8.0.1, since GHC now does properly detect the impredicative instantiation: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug2.hs, interpreted ) Bug2.hs:14:13: error: • Cannot instantiate unification variable ‘a0’ with a type involving foralls: (forall a. a -> a) -> b0 GHC doesn't yet support impredicative polymorphism • In the second argument of ‘(.)’, namely ‘rank2’ In the expression: foo . rank2 In the expression: foo . rank2 $ quux | 14 | bar = foo . rank2 $ quux | ^^^^^ Bug2.hs:14:21: error: • Cannot instantiate unification variable ‘a0’ with a type involving foralls: (forall a. a -> a) -> Int GHC doesn't yet support impredicative polymorphism • In the second argument of ‘($)’, namely ‘quux’ In the expression: foo . rank2 $ quux In an equation for ‘bar’: bar = foo . rank2 $ quux | 14 | bar = foo . rank2 $ quux | ^^^^ }}} (See also #11319 for the plan to allow such impredicative instantiations via `TypeApplications`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 22:29:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 22:29:15 -0000 Subject: [GHC] #14451: Type synonym of type family causes error, error jumps to (fairly) unrelated source location In-Reply-To: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> References: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> Message-ID: <066.82dfd898caa42fb6c46c2e206f81978b@haskell.org> #14451: Type synonym of type family causes error, error jumps to (fairly) unrelated source location -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 RyanGlScott): The error message thing is a red herring: the real culprit is lurking in this slightly minimized version of your program: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} import Data.Kind data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type type family Apply (f :: a ~> b) (x :: a) :: b where Apply (CompSym2 f g) a = Comp f g a data CompSym2 :: (b ~> c) -> (a ~> b) -> (a ~> c) type (a :: k1 ~> k2) · (b :: k1) = Apply a b type family Comp (f::k1 ~> k) (g::k2 ~> k1) (a::k2) :: k where Comp f g a = f · (g · a) }}} This appears to typecheck without issues. But there actually //is// an issue, if you poke around inside the file with GHCi: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Ok, 1 module loaded. λ> :k (·) (·) :: (k2 ~> k2) -> k2 -> k2 }}} Egad! Despite the fact that we've appeared to give `(·)` the kind `(k1 ~> k2) -> k1 -> k2`, GHC somehow concludes that it actually has the more restrictive kind `(k2 ~> k2) -> k2 -> k2`. (This, in turn, causes the strange error message you've observed.) As far as why this happens, my shot-in-the-dark guess is that this is a manifestation of #11203/#11453. But I'd need Richard to confirm this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 22:43:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 22:43:11 -0000 Subject: [GHC] #14349: Semigroup/Monoid instances for System.Exit.ExitCode In-Reply-To: <050.38ed5b1d7f57b93168c3a6f1a83443f4@haskell.org> References: <050.38ed5b1d7f57b93168c3a6f1a83443f4@haskell.org> Message-ID: <065.bd3cb47bca8103033fd8f6105ec9ca54@haskell.org> #14349: Semigroup/Monoid instances for System.Exit.ExitCode -------------------------------------+------------------------------------- Reporter: neil.mayhew | Owner: (none) Type: feature request | Status: upstream Priority: low | Milestone: Component: libraries/base | Version: 8.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 neil.mayhew): Since there's been no further discussion, I'll assume that's a no to my monoid proposal. However, I've been thinking about it some more, and I've come up with a solution that I think will be more acceptable (based on previous comments). Since `ExitCode` is structurally identical to `Maybe Int`, and since `Maybe` already has a lot of useful typeclass instances, I propose an isomorphism as follows: {{{#!hs -- | Case analysis for the 'ExitCode' type exitCode :: a -> (Int -> a) -> ExitCode -> a exitCode x _ ExitSuccess = x exitCode _ f (ExitFailure i) = f i exitCodeToMaybe :: ExitCode -> Maybe Int exitCodeToMaybe = exitCode Nothing Just maybeToExitCode :: Maybe Int -> ExitCode maybeToExitCode = maybe ExitSuccess ExitFailure }}} Then it would be possible to use `Monoid` instances of newtype wrappers such as `First/Last` or use `Maybe`'s `MonadPlus` or `Alternative` instances. In particular, `msum`/`asum` has the behaviour I'm looking for: {{{#!hs >>> msum [Nothing, Just 1, Nothing, Just 3] Just 1 }}} This would allow the following: {{{#!hs exitWith . maybeToExitCode . msum $ mapM (exitCodeToMaybe <$> system) commands }}} This could be further cleaned up: {{{#!hs exitWith' :: Maybe Int -> IO () exitWith' = exitWith . maybeToExitCode system' :: String -> IO (Maybe Int) system' = exitCodeToMaybe <$> system main = exitWith' . msum . mapM system' $ commands }}} I would be in favour of providing `exitWith'` in `System.Exit` (eg as `exitWithMaybe`) but it's less easy to argue that `system'` should be provided (eg as `systemWithMaybe`) because there are several other functions in `System.Process` that return an `ExitCode` and it would be awkward to provide `Maybe` variants of all of them. So, is adding the isomorphism functions a possibility? What about `exitWithMaybe`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 23:02:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 23:02:41 -0000 Subject: [GHC] #14425: approxRational is wrong when (rat - eps) overflows in negative direction In-Reply-To: <046.eb71da6200dae7e365172a0968ad4790@haskell.org> References: <046.eb71da6200dae7e365172a0968ad4790@haskell.org> Message-ID: <061.68cee078c566544c89aa2b60d9eb278d@haskell.org> #14425: approxRational is wrong when (rat - eps) overflows in negative direction -------------------------------------+------------------------------------- Reporter: danielk | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: T14425 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4168 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 23:02:46 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 23:02:46 -0000 Subject: [GHC] #13990: Core Lint error on empty case In-Reply-To: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> References: <047.23c384a179f5b63bb15fe7bf4b3c30b5@haskell.org> Message-ID: <062.7bd0a7318001f9a6118b1f6ce38b3b07@haskell.org> #13990: Core Lint error on empty case -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1-rc3 Resolution: fixed | Keywords: core-lint | case Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4160 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 23:02:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 23:02:51 -0000 Subject: [GHC] #14311: PowerPC: Symbol already defined In-Reply-To: <047.517ec9911119ab317a73da8842dce7f3@haskell.org> References: <047.517ec9911119ab317a73da8842dce7f3@haskell.org> Message-ID: <062.c4898d9ee39eaa87d726e07b22e75628@haskell.org> #14311: PowerPC: Symbol already defined ----------------------------------------+------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | 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 Sat Nov 11 23:43:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 23:43:43 -0000 Subject: [GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects In-Reply-To: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> References: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> Message-ID: <064.0a5ccb2ca468aeff22ea325e47b97645@haskell.org> #14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: angerman Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | 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 shlevy): Note that in nixpkgs we have a solution that will always let us stay under the limit (essentially using intermediate libraries that reexport symbols from all the libraries underneath them) https://github.com/NixOS/nixpkgs/pull/27536 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 23:47:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 23:47:21 -0000 Subject: [GHC] #14454: Unregisterised build is broken Message-ID: <046.16eab3f0c63c2818b23a6ad81d240445@haskell.org> #14454: Unregisterised build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- Fails with several errors along the lines of, {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20171111 for x86_64-unknown-linux): pprCLbl AsmTempLabel Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug rts/ghc.mk:295: recipe for target 'rts/dist/build/Exception.o' failed make[1]: *** [rts/dist/build/Exception.o] Error 1 make[1]: *** Waiting for unfinished jobs.... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 11 23:47:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Nov 2017 23:47:43 -0000 Subject: [GHC] #14454: Unregisterised build is broken In-Reply-To: <046.16eab3f0c63c2818b23a6ad81d240445@haskell.org> References: <046.16eab3f0c63c2818b23a6ad81d240445@haskell.org> Message-ID: <061.c14e8edca35621cd7af981de9b0c79c9@haskell.org> #14454: Unregisterised build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 02:22:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 02:22:55 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.f22319098692a0f2cda2cdeedee9e537@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): The only reason I was suggesting a criterion was to reduce the perf impact in real-world code. However, if it is simple to implement this for every function, and we find the perf impact to be negligible, it is better than having an ad-hoc criterion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 10:32:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 10:32:24 -0000 Subject: [GHC] #14353: PowerPC: HEAD validate fails due to warnings in libffi In-Reply-To: <047.961ea899fd8ff2b7dcf4d0bb882f6d5d@haskell.org> References: <047.961ea899fd8ff2b7dcf4d0bb882f6d5d@haskell.org> Message-ID: <062.05960585337bce2b4258f0082eddf566@haskell.org> #14353: PowerPC: HEAD validate fails due to warnings in libffi ----------------------------------------+-------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+-------------------------------- Changes (by trommler): * owner: (none) => trommler * component: Compiler => Runtime System -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 12:23:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 12:23:31 -0000 Subject: [GHC] #14398: Fail to install haskell platform on Windows In-Reply-To: <045.d86ee14cadb946edd5536f02e4b96185@haskell.org> References: <045.d86ee14cadb946edd5536f02e4b96185@haskell.org> Message-ID: <060.715994db593de888b8288530c8580b4e@haskell.org> #14398: Fail to install haskell platform on Windows -------------------------------------+------------------------------------- Reporter: KAAAsS | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #14168 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * Attachment "filters.zip" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 12:25:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 12:25:08 -0000 Subject: [GHC] #14398: Fail to install haskell platform on Windows In-Reply-To: <045.d86ee14cadb946edd5536f02e4b96185@haskell.org> References: <045.d86ee14cadb946edd5536f02e4b96185@haskell.org> Message-ID: <060.7ddaa383992ff787a6d0ed926b9bdca2@haskell.org> #14398: Fail to install haskell platform on Windows -------------------------------------+------------------------------------- Reporter: KAAAsS | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #14168 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Thanks @KAAAsS, unfortunately you did not seem to have any filters selected, so the capture file is mostly empty. Could you try again, but this time before you start capturing go to `Filter` -> `Load` and select the xml file in the zip file I attached here. This should enable the right APIs to monitor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 13:15:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 13:15:54 -0000 Subject: [GHC] #14398: Fail to install haskell platform on Windows In-Reply-To: <045.d86ee14cadb946edd5536f02e4b96185@haskell.org> References: <045.d86ee14cadb946edd5536f02e4b96185@haskell.org> Message-ID: <060.b47d462a6644390fc83aa5a37770c138@haskell.org> #14398: Fail to install haskell platform on Windows -------------------------------------+------------------------------------- Reporter: KAAAsS | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #14168 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by KAAAsS): I tried to use the filter below, but it captured nothing. I don't know what's the wrong with it. Here is the capture file: https://1drv.ms/u/s!AsbnyYMkwdNRjFv1vgyL4ePq4dNs And it seems like I had captured sth without filter file: https://1drv.ms/u/s!AsbnyYMkwdNRjFwPJuzex5fv-i5e Hope it'll be useful. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 13:28:43 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 13:28:43 -0000 Subject: [GHC] #14437: Optimise remainders by powers of two In-Reply-To: <047.291113040ac7c3813fee479e4d1a965e@haskell.org> References: <047.291113040ac7c3813fee479e4d1a965e@haskell.org> Message-ID: <062.c7eb3d28e4299a66a2ff61e53e572bbc@haskell.org> #14437: Optimise remainders by powers of two -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: Bodigrim Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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): Phab:D4180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Bodigrim): * owner: (none) => Bodigrim * differential: => Phab:D4180 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 13:29:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 13:29:22 -0000 Subject: [GHC] #14437: Optimise remainders by powers of two In-Reply-To: <047.291113040ac7c3813fee479e4d1a965e@haskell.org> References: <047.291113040ac7c3813fee479e4d1a965e@haskell.org> Message-ID: <062.b1ddbee114118e4ea5b7b466d7bfaa25@haskell.org> #14437: Optimise remainders by powers of two -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: Bodigrim Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.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): Phab:D4180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Bodigrim): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 14:43:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 14:43:20 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.f0ef81af2c967a0d95e9be7db5795c65@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 bgamari): I think the best way to approach this would just be to run an experiment. Hack your suggested change into the compiler and measure the effect on real-world code. My suspicion is that this will show that performance regresses by approximately the same amount as `-fprof-auto -prof` since operationally the two approaches are somewhat similar. However, this does raise a question: What prevents you from just using cost center stacks? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 15:16:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 15:16:15 -0000 Subject: [GHC] #14455: PPC64: Wrong output in print022 Message-ID: <047.0bdf060fac19303d5cc090cf0af4b401@haskell.org> #14455: PPC64: Wrong output in print022 -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.3 Keywords: big endian | Operating System: Unknown/Multiple Architecture: powerpc64 | Type of failure: Incorrect result Test Case: | at runtime ghci.debugger/scripts/print022 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On powerpc64 Linux print022 fails with the following: {{{ -test = C 1 32 1.2 1.23 'x' 1 1.2 1.23 +test = C 1 32 0.0 1.23 'x' 1 1.2 1.23 }}} Note, the fourth item is 0.0 instead of 1.2. In ticket #11262 the fourth item was still correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 15:21:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 15:21:37 -0000 Subject: [GHC] #14455: PPC64: Wrong output in print022 In-Reply-To: <047.0bdf060fac19303d5cc090cf0af4b401@haskell.org> References: <047.0bdf060fac19303d5cc090cf0af4b401@haskell.org> Message-ID: <062.bbdc49b1746f5b12117f39c82b9835f2@haskell.org> #14455: PPC64: Wrong output in print022 -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.3 Resolution: | Keywords: big endian Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | ghci.debugger/scripts/print022 | ghci.debugger/scripts/T13825-debugger Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * testcase: ghci.debugger/scripts/print022 => ghci.debugger/scripts/print022 ghci.debugger/scripts/T13825-debugger Comment: From the diff of T13825-debugger: {{{ -Packed1 12.34# 56.78# 42# 99.99# -packed1 = Packed1 12.34 56.78 42 99.99 +Packed1 0.0# 0.0# 42# 0.0# +packed1 = Packed1 0.0 0.0 42 0.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 17:21:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 17:21:09 -0000 Subject: [GHC] #14353: PowerPC: HEAD validate fails due to warnings in libffi In-Reply-To: <047.961ea899fd8ff2b7dcf4d0bb882f6d5d@haskell.org> References: <047.961ea899fd8ff2b7dcf4d0bb882f6d5d@haskell.org> Message-ID: <062.0bb189e73479e1c1a7f7497ecb3fda42@haskell.org> #14353: PowerPC: HEAD validate fails due to warnings in libffi ----------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4181 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by trommler): * status: new => patch * differential: => Phab:D4181 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 17:54:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 17:54:59 -0000 Subject: [GHC] #14454: Unregisterised build is broken In-Reply-To: <046.16eab3f0c63c2818b23a6ad81d240445@haskell.org> References: <046.16eab3f0c63c2818b23a6ad81d240445@haskell.org> Message-ID: <061.edafbefff953fa03cf625974a1c9def1@haskell.org> #14454: Unregisterised build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.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 bgamari): This broke due to 8b007abbeb3045900a11529d907a835080129176. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 17:57:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 17:57:01 -0000 Subject: [GHC] #14454: Unregisterised build is broken In-Reply-To: <046.16eab3f0c63c2818b23a6ad81d240445@haskell.org> References: <046.16eab3f0c63c2818b23a6ad81d240445@haskell.org> Message-ID: <061.92833fc42aa19e57ad599bf338bc8009@haskell.org> #14454: Unregisterised build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 18:03:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 18:03:26 -0000 Subject: [GHC] #14456: Windows runtime linker failure with icuuc Message-ID: <050.3b07902cfc2f558e6740649e9c204478@haskell.org> #14456: Windows runtime linker failure with icuuc -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First, install `mingw-w64-x86_64-icu` (I'm using version 58.2-2): {{{ $ pacman -S mingw-w64-x86_64-icu }}} Now take this file: {{{#!hs module Main where import Data.Int import Foreign foreign import ccall "ucnv_getMaxCharSize_58" c_ucnv_getMaxCharSize :: Ptr () -> IO Int8 main :: IO () main = c_ucnv_getMaxCharSize nullPtr >>= print }}} GHC is able to compile this successfully: {{{ $ ghc -licuuc Bug2.hs [1 of 1] Compiling Main ( Bug2.hs, Bug2.o ) Linking Bug2.exe ... }}} But GHCi is unable to accomplish the same thing: {{{ $ runghc -licuuc Bug2.hs ghc.exe: ^^ Could not load 'ucnv_getMaxCharSize_58', dependency unresolved. See top entry above. Bug2.hs: ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: ucnv_getMaxCharSize_58 This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs at haskell.org }}} Phyx- and I discussed this briefly on IRC. He suspected that the fact that `C:\Windows\System32` now contains its own copy of `icuuc.dll` is contributing to the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 18:07:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 18:07:53 -0000 Subject: [GHC] #14457: Data family with non-Type return kind, can't figure out type despite annotating Message-ID: <051.8099f6cbc7b606a494b329c466d140e8@haskell.org> #14457: Data family with non-Type return kind, can't figure out type despite annotating -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12369 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language KindSignatures, DataKinds, TypeFamilyDependencies, GADTs, TypeInType #-} import Data.Kind type family ToNat (n::Type) = (res :: Type) | res -> n where ToNat Type = Bool ToNat (Type -> Type) = Maybe Bool data family FN :: ToNat ty -> ty data instance FN :: Bool -> Type where F :: FN False T :: FN True data instance FN :: Maybe Bool -> (Type -> Type) where A :: FN (Nothing :: Maybe Bool) a B :: a -> FN (Just False) a C :: a -> a -> FN (Just True) a }}} works on GHC 8.3.20170920, but removing the annotation from `(Nothing :: Maybe Bool)` yields {{{ GHCi, version 8.3.20170920: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Z.hs, interpreted ) /tmp/Z.hs:19:22: error: • Expected kind ‘ToNat (k0 -> *)’, but ‘Nothing’ has kind ‘Maybe a0’ • In the first argument of ‘FN’, namely ‘Nothing’ In the type ‘FN Nothing a’ In the definition of data constructor ‘A’ | 19 | A :: FN Nothing a | ^^^^^^^ Failed, 0 modules loaded. Prelude> }}} even though `FN` is annotated with the expected kind of `Nothing`: {{{#!hs data FN :: Maybe Bool -> ... where }}} can also be fixed by annotating `A :: FN Nothing (a::Type)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 18:10:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 18:10:00 -0000 Subject: [GHC] #14456: Windows runtime linker failure with icuuc In-Reply-To: <050.3b07902cfc2f558e6740649e9c204478@haskell.org> References: <050.3b07902cfc2f558e6740649e9c204478@haskell.org> Message-ID: <065.5b81c800837720e05cacd737452764a0@haskell.org> #14456: Windows runtime linker failure with icuuc -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Phyx- notes that while there's no obvious workaround for this on GHC 8.2, there is on GHC HEAD, where you can manually specify: {{{ $ runghc -licuuc.dll.a Bug2.hs }}} In theory, this should be equivalent: {{{ $ runghc -llibicuuc.dll.a Bug2.hs }}} But in practice, GHC doesn't permit this, as there's a case missing in the runtime linker code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 18:31:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 18:31:02 -0000 Subject: [GHC] #14457: Data family with non-Type return kind, can't figure out type despite annotating In-Reply-To: <051.8099f6cbc7b606a494b329c466d140e8@haskell.org> References: <051.8099f6cbc7b606a494b329c466d140e8@haskell.org> Message-ID: <066.fe38980a2c42c2542af74be0b88e75c1@haskell.org> #14457: Data family with non-Type return kind, can't figure out type despite annotating -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12369, #14111 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: #12369 => #12369, #14111 Comment: This is a duplicate of #14111, so I'll close this ticket in favor of that one. The issue actually has nothing to do with the return kind. We can see this in this stripped-down version of your example: {{{#!hs {-# Language KindSignatures, DataKinds, TypeFamilyDependencies, GADTs, TypeInType #-} import Data.Kind type family ToNat (n::Type) = (res :: Type) | res -> n where ToNat Type = Bool ToNat (Type -> Type) = Maybe Bool data family FN (a :: k) (b :: Type) :: Type data instance FN (a :: Maybe Bool) (b :: Type) :: Type where A :: FN Nothing a }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:14:3: error: • Data constructor ‘A’ returns type ‘FN 'Nothing a1’ instead of an instance of its parent type ‘FN a b’ • In the definition of data constructor ‘A’ In the data instance declaration for ‘FN’ | 14 | A :: FN Nothing a | ^ }}} In principle, there should be enough types here that GHC can figure out what to do, but unfortunately that's not the case at the moment (due to #14111). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 18:31:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 18:31:30 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.5cc56a5f2b433c51e8809d9aa0d873cb@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14457 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 21:53:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 21:53:35 -0000 Subject: [GHC] #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) In-Reply-To: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> References: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> Message-ID: <064.da126787104e90a175a7a32424f485a0@haskell.org> #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) -------------------------------------+------------------------------------- Reporter: carlostome | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: profiler Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14006, #11645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): I had a little look at this. The description in comment:2 looks right to me, except that I think ALL censuses are using stale stats.gc.cpu_ns values. I moved the `stats_endGC` call before the `heapCensus` call in phab:D4183, and this issue seems to be fixed. Of course it's quite hard to tell that this doesn't break something else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 22:01:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 22:01:11 -0000 Subject: [GHC] #5889: -fno-prof-count-entries leads to linking errors In-Reply-To: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> References: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> Message-ID: <058.91704001ddd4f9339d732598057f195b@haskell.org> #5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * testcase: => profiling/should_compile/T5889 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 22:28:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 22:28:18 -0000 Subject: [GHC] #14458: ghc: panic! -- initTc: unsolved constraints Message-ID: <045.c91f668c10397bdce6ee5a491b150a8e@haskell.org> #14458: ghc: panic! -- initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: lijero | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- So this is an interesting bug. If I mistype parse' as parse, /and/ do not have main defined, the error occurs, but not with either individual one. I'm sure the code sucks, but I wasn't intending for this to end up anywhere, it just happened to trigger the crash. {{{ lijero at desktop:~/code/ab$ ghc AB.hs [1 of 1] Compiling Main ( AB.hs, AB.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] parse_ay8 :: t_ay7[tau:1] (CHoleCan: parse) [W] parse_ayp :: t_ayo[tau:1] (CHoleCan: parse)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{#!hs module Main where data Token = KUnit | KApp | KLam | KVar String data Ast = AUnit | AApp Ast Ast | ALam Ast Ast | AVar String parse' :: [Token] -> ([Token] -> Ast -> Maybe Ast) -> Maybe Ast parse' (KUnit:xs) fail = fail xs AUnit -- GHC does not crash when parse is correctly written parse' in both of the below instances parse' (KApp:xs) fail = parse' xs (\ xs' f -> AApp f <$> parse xs' fail) parse' (KLam:xs) fail = parse' xs (\ xs' a -> ALam a <$> parse xs' fail) parse' (KVar n:xs) fail = fail xs (AVar n) -- GHC does not crash when main is defined --main :: IO () --main = putStrLn "" }}} With main defined, GHC correctly reports "variable not in scope". With parse corrected to parse', GHC correctly reports that main is not defined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 22:31:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 22:31:56 -0000 Subject: [GHC] #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) In-Reply-To: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> References: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> Message-ID: <064.d8abd15530ed45917d3e7da745ed8035@haskell.org> #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) -------------------------------------+------------------------------------- Reporter: carlostome | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: profiler Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14006, #11645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks for picking this up, duog! I was in the middle of writing a reply starting with, > The issue with this approach is that we will now have runtime which won't be accounted for. The heap census can be a considerable amount of time... when I noticed that we already have a separate set of fields for accounting heap census time. Presumably this means that we were double- counting time previously. Anyways, this suggests to me at least that your approach should be fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 22:42:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 22:42:17 -0000 Subject: [GHC] #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) In-Reply-To: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> References: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> Message-ID: <064.9c0e6d907d13226a6f17b4c6719a7a88@haskell.org> #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) -------------------------------------+------------------------------------- Reporter: carlostome | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: profiler Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14006, #11645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): > when I noticed that we already have a separate set of fields for accounting heap census time. Presumably this means that we were double- counting time previously. Anyways, this suggests to me at least that your approach should be fine. I don't ''think'' we were double counting. `stat_endGC` is only accounting for time, it doesn't call `getProcessTimes`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 12 23:05:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Nov 2017 23:05:29 -0000 Subject: [GHC] #14458: ghc: panic! -- initTc: unsolved constraints In-Reply-To: <045.c91f668c10397bdce6ee5a491b150a8e@haskell.org> References: <045.c91f668c10397bdce6ee5a491b150a8e@haskell.org> Message-ID: <060.e227b1aa86659012257afd4baee80995@haskell.org> #14458: ghc: panic! -- initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: lijero | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13106 Comment: Thanks for the bug report. This is a duplicate of #13106, and has been fixed in GHC 8.2: {{{ $ /opt/ghc/8.2.1/bin/ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Bug.hs:1:1: error: The IO action ‘main’ is not defined in module ‘Main’ | 1 | module Main where | ^ Bug.hs:17:36: error: • Variable not in scope: parse :: [Main.Token] -> ([Main.Token] -> Main.Ast -> Maybe Main.Ast) -> Maybe Main.Ast • Perhaps you meant ‘parse'’ (line 14) | 17 | parse' xs (\ xs' f -> AApp f <$> parse xs' fail) | ^^^^^ Bug.hs:19:36: error: • Variable not in scope: parse :: [Main.Token] -> ([Main.Token] -> Main.Ast -> Maybe Main.Ast) -> Maybe Main.Ast • Perhaps you meant ‘parse'’ (line 14) | 19 | parse' xs (\ xs' a -> ALam a <$> parse xs' fail) | ^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 00:50:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 00:50:34 -0000 Subject: [GHC] #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) In-Reply-To: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> References: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> Message-ID: <064.f7d0fd504ef6311967bc48d7c2079bfd@haskell.org> #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) -------------------------------------+------------------------------------- Reporter: carlostome | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: profiler Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14006, #11645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): Having done some more investigation, my understanding has improved. The diff linked in comment:8 is quite wrong. `heapCensus` should be called during a garbage collection, and it's time should be included in GC stats. It's parameter should be the start time of the current gc. I now believe the cause of this is a bug in how gc times are accumulated, see Phab:4184, which does fix this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 01:54:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 01:54:00 -0000 Subject: [GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects In-Reply-To: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> References: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> Message-ID: <064.5b62c8240b4f80eed9c69db8405bde9c@haskell.org> #14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: angerman Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | 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 chak): * cc: chak (added) Comment: > bgamari: I've been asking people to open tickets with Apple > bgamari: As they are really the only ones that can really fix this issue I am quite sure I know what Apple will respond: "You are holding it wrong." Insider jokes aside, the core problem (as I mentioned before on one of the other tickets) is that GHC tries to use the macOS linker like a Linux linker and it was never meant to be used like that. Hence, Apple will only tell you to use it how it was designed to be used. (This is why I haven't filled a Radar —Apple speak for bug report— against this issue myself.) As @angerman und @shlevy explained, there are alternatives to GHC's current scheme, which are closer to how library paths are usually managed on macOS. In addition, there is a reason why library names on macOS can include directory paths. In combination with @loader_path and @executable_path that always allowed to drastically shorten GHC's load command size. Haskell for Mac has done this for a long time (and I also mentioned this on a previous ticket) — see https://github.com/haskellformac/GHCframework/blob/master/GHCBuild/BuildGHC.sh for a messy shell script that is part of how the Haskell for Mac build handles this. (The other parts are in that repo as well.) What I am trying to say here is that Apple will not change this, as they do not consider it a problem caused by macOS, but as a problem caused by GHC's abuse of the MACH-O linker format. Hence, I am afraid, we will have to fix this on our side. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 02:59:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 02:59:48 -0000 Subject: [GHC] #14451: Type synonym of type family causes error, error jumps to (fairly) unrelated source location In-Reply-To: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> References: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> Message-ID: <066.b84334a2d7f08b86c4f57d364526c0ad@haskell.org> #14451: Type synonym of type family causes error, error jumps to (fairly) unrelated source location -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType 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): * keywords: => TypeInType Comment: Yes, this could be #11203, but I haven't done enough analysis to be sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 03:03:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 03:03:05 -0000 Subject: [GHC] #14450: GHCi spins forever In-Reply-To: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> References: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> Message-ID: <066.3352cc60112433e98377670fc5c61e87@haskell.org> #14450: GHCi spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | PolyKinds 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 goldfire): OK -- I'll take a look in due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 03:38:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 03:38:37 -0000 Subject: [GHC] #14445: GC timing stats (e.g. mutator_elapsed_ns) decrease over time In-Reply-To: <047.81a01718a79512286f0bf0342273b9da@haskell.org> References: <047.81a01718a79512286f0bf0342273b9da@haskell.org> Message-ID: <062.7bd80fb196bd75de46a5cfb4d52eda1c@haskell.org> #14445: GC timing stats (e.g. mutator_elapsed_ns) decrease over time -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #14257, #14006, | Differential Rev(s): #11645 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): I observed this bug, then applied Phab:D4184, and it seems to fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 06:05:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 06:05:41 -0000 Subject: [GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects In-Reply-To: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> References: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> Message-ID: <064.4146c9060b72d5d54e1c8a6a28cafc64@haskell.org> #14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: angerman Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | 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 angerman): chak, thank you for putting this out here as well! I still plan to fix this properly in GHC. I'm not sure I will be able to do this for 8.4. The "fix" in cabal was a quick hack to make cabal work, as I had a project which needed to compile and I could not bump GHC. As such cabal needed to learn to be a bit more conservative about RPTAHs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 07:07:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 07:07:56 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.85d08d82382778c09f31697e8bab7bea@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): > My suspicion is that this will show that performance regresses by approximately the same amount as -fprof-auto -prof since operationally the two approaches are somewhat similar. Where can I read more about what `-fprof-auto -prof` does? > However, this does raise a question: What prevents you from just using cost center stacks? By cost-center stacks, do you mean whatever `-prof` does? Upon an exception, does it give a proper callstack? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 08:35:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 08:35:37 -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.0282d5afe269bc4560a7b5f53db018a1@haskell.org> #9052: Support a "stable heap" which doesn't get garbage collected -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: Component: Runtime System | 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): Phab:D1264 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 11:08:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 11:08:37 -0000 Subject: [GHC] #14335: Annotations aren't supported with -fexternal-interpreter In-Reply-To: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> References: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> Message-ID: <061.e430a2c01278deba017928371a5f7070@haskell.org> #14335: Annotations aren't supported with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Would a regression test be appropriate, to ensure it doesn't recur? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 13:54:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 13:54:15 -0000 Subject: [GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects In-Reply-To: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> References: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> Message-ID: <064.612f2660328eb6634e5b3dbb80509ae3@haskell.org> #14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: angerman Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | 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 dredozubov): FWIW nix people use symlinks to lower the command size https://github.com/NixOS/nixpkgs/blob/a2bebdd6cedb58819cc1738282b9f02964d34a9a/pkgs/development /haskell-modules/generic-builder.nix#L239 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 14:11:34 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 14:11:34 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.90d088074473e073d6fe7325bdb2c456@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 gridaphobe): Replying to [comment:30 bgamari]: > > So, how do we take it forward from here? Is it possible to have HasCallStack automatically for functions in IO and/or above a certain cost threshold? > > I think we'll need to define the criterion here a bit more precisely. In particular, it's not clear that doing this in a completely type-driven way makes sense. For instance, what about a function in `MaybeT IO`? Yeah, and it gets even worse when you think about things like `MonadIO`, `MonadBaseControl`, etc. > Using a size-threshold sounds plausible but feels a bit ad-hoc. I agree. I'm pretty reluctant to tie a user-facing feature like `HasCallStack` to GHC's size heuristics, that would make it quite difficult for users to reason about which functions will get an automatic constraint. And worse, there doesn't seem to be any reason to expect a size heuristic to produce a proper **chain** of callstack-aware functions. > However, this does raise a question: What prevents you from just using cost center stacks? Well, cost-center stacks require the entire world to have been compiled with `-prof`, which can be pretty time-consuming. In contrast, `HasCallStack` could be enabled on a per-module basis while maintaining interoperability with non-`HasCallStack` code. I feel like this could be a useful debugging tool, though it is somewhat limited in scope, i.e. in the limit it clearly devolves to a manual version of the `-prof` way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 14:23:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 14:23:53 -0000 Subject: [GHC] #14338: Simplifier fails with "Simplifier ticks exhausted" In-Reply-To: <049.819ef8e60a65cb9f3e29afb8f69166a7@haskell.org> References: <049.819ef8e60a65cb9f3e29afb8f69166a7@haskell.org> Message-ID: <064.b9103fef4a6b033fc06859262dbed835@haskell.org> #14338: Simplifier fails with "Simplifier ticks exhausted" -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dredozubov): I ran into a few issues running this on my machine, so I made a few changes, maybe it'll be helpful to someone else: {{{ $ git clone git at github.com:dredozubov/webapp-template-hs.git $ cd webapp-template-hs $ git checkout simpl-tick-factor $ export ghc=$PATH_TO_GHC $ cabal new-build -w $ghc --only-dependencies $ n=9 ./build_all.sh -package-db PATH_TO_PACKAGE_DB }}} Path to package db was `~/.cabal/store/ghc-8.3.20171108/package.db` for me -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 15:00:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 15:00:08 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.69cbac250761d5bd74f56dba780a6d70@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): Replying to [comment:88 simonpj]: > Hmm. The `Cmm` for `g10` is actually a lot bigger than that for `f10`, and looked to me as if it too would scale quadratically. It would, but for different reasons, and I believe I can rewrite it to not scale quadratically (but haven't gotten around to it yet). > Are `f10` and `g10` accurate reflections of the "scale well" and "scale badly" versions of Read? No; we don't actually have a "scale well" version of `Read` yet. All the implementations of `Read` that I have produced so far are in the "scale badly" category, although the degree to which they scale badly differs somewhat. We have two kinds of "scale well" examples: 1. Trivial ones, where rather than nest code such that chains of closures appear, we just call `read` or something else N times, but in benign ways; these examples do not have much of an explanatory value, and I merely included them to establish a performance baseline 2. Well-behaved nested / chained examples, such as the `getline-appl` one; however, none of these do anything equivalent to `read`. > > I can see why things might scale badly, if we have a lot of > {{{ > p1 >>= \x -> > p2 >>= \y -> > p3 >>= \z -> > return (K x y z) > }}} > And `f10` has that structure, albeit with data constructors rather than functions. BUT: if that's it, why doesn't `(>>=)` inline, so we get a case expression instead?? I believe the `(>>=)` does in fact inline; `f10` is the kind of shape you get when you inline the `(>>=)` from `ReadP`. `(>>=)` from other monadic types does not introduce this kind of shape, which would explain why `Read` misbehaves but `getLine` over `IO` does not. > > So if `f10` is reasonably accurate, I can see two ways forward: > > 1 Do something in the back end to generate less code. > > 2 Generate different code. I'm still intrigued (and a bit disbelieving) why a different exposition of Read generates code that scales better. See above; `Read` always misbehaves here, so your disbelief is entirely justified. The bad behavior seems to be related to the actual implementation of `(>>=)`, not so much whether the `(>>=)` gets inlined. Or, more accurately, inlining `(>>=)` actually *is* the problem; if we didn't inline it, then `read-appl` would compile to something equivalent to the generic applicative example, which behaves nicely. > Concerning (1) the kind of thing I had in mind was more like this > {{{ > f10 = > A (\i0 -> > A (\i1 -> > A (\i2 -> > A (\i3 -> > A (\i4 -> let t = (i0,i1,i2,i3,i4) in > A (\i5 -> > A (\i6 -> > A (\i7 -> > A (\i8 -> > A (\i9 -> > case t of (i0,i1,i2,i3,i4) -> > N (i0, i1, i2, i3, i4, i5, i6, i7, i8, i9) > }}} > Now no function closure gets more than 5 free variables. I imagine one could do this as a STG-to-STG transformation if we decided that this was really the core issue. Further experimentation shows that this doesn't actually achieve anything; the resulting Core is *exactly the same*, and if you put both functions into the same compilation unit, they get optimized into expressing one in terms of the other (I'm guessing here that CSE is smart enough to figure out that they are equivalent). I have written 3 versions of `f10`, one as- is, one (`g10`) using the suggested 5-tuple optimization, and one (`h10`) using a nested-tuple optimization, and I end up with Core that has literally these lines: {{{ f10 = A f1 g10 = f10 h10 = f10 }}} > A tantalising point is this. We have something like this: > {{{ > let f4 = [i0,i1,i2,i3] \i4 -> > let f5 = [i0,i1,i2,i3, i4] \i5 -> ...blah... > }}} > The list before the `\` are the free vars of the closure. > > Inside the code for `f4` we have `f4`'s function closure in hand, with `i0...` in it. Rather than capturing `i0, i1...` as the free vars of f5, we could just store a pointer to `f4`'s function closure (it's a kind of tuple, after all) and fetch its free vars from there. It's as if we wanted to say > {{{ > let f4 = [i0,i1,i2,i3] \i4 -> > let f5 = [f4, i4] \i5 -> ...blah... > }}} > with `f4` and `i4` being the free vars of `f5`'s closure. This would be a deeper change to the code generator, but it could make a lot of sense in cases where ''all'' of `f4`'s free variables are also free in `f5`. (If not all where, you might get a space leak by closing over `f4`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 15:34:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 15:34:35 -0000 Subject: [GHC] #14459: `make sdist-ghc` broken Message-ID: <042.28c91cc808d02e803cb2f4f0dc8cbb78@haskell.org> #14459: `make sdist-ghc` broken -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.3 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 noticed this because it resulted in the PPA builds of GHC HEAD failing; I was able to hunt this down to bdd2d2862e248948efafa8ba4219e94825ddf21a which updated `libraries/Cabal`; Basically, the following invocation (where `ghc`/`alex`/`happy`/etc. can only be found in `/opt/ghc-stage0-toolchain/bin`, and nowhere else; so this relies on `configure` to capture their absolute locations; however, this is not what causes the failure below) {{{#!bash ./boot PATH=/opt/ghc-stage0-toolchain/bin:$PATH ./configure make sdist-ghc }}} results in {{{ ... test ! -d testsuite || make -C testsuite distclean "rm" -rf sdistprep/ghc/ghc-8.3.20171109/libraries/tarballs/ "rm" -rf sdistprep/ghc/ghc-8.3.20171109/libraries/stamp/ "rm" -rf sdistprep/ghc/ghc-8.3.20171109/compiler/stage[123] "rm" -f sdistprep/ghc/ghc-8.3.20171109/mk/build.mk for i in parallel random primitive vector dph; do rm -rf sdistprep/ghc/ghc-8.3.20171109/libraries/$i/; done cd sdistprep/ghc/ghc-8.3.20171109 && "/usr/bin/find" mk rules docs distrib bindisttest libffi includes utils docs rts compiler ghc driver libraries libffi-tarballs iserv \( -name .git -o -name "autom4te*" -o -name "*~" -o -name "\#*" -o -name ".\#*" -o -name "log" -o -name "*-SAVE" -o -name "*.orig" -o -name "*.rej" \) -print | "xargs" "rm" -rf "cp" compiler/stage2/build/CmmLex.hs sdistprep/ghc/ghc-8.3.20171109/compiler/cmm mv sdistprep/ghc/ghc-8.3.20171109/compiler/cmm/CmmLex.x sdistprep/ghc/ghc-8.3.20171109/compiler/cmm/CmmLex.x.source "/opt/ghc-stage0-toolchain/bin/happy" -agc --strict compiler/cmm/CmmParse.y -o compiler/stage2/build/CmmParse.hs "cp" compiler/stage2/build/CmmParse.hs sdistprep/ghc/ghc-8.3.20171109/compiler/cmm mv sdistprep/ghc/ghc-8.3.20171109/compiler/cmm/CmmParse.y sdistprep/ghc/ghc-8.3.20171109/compiler/cmm/CmmParse.y.source "/opt/ghc-stage0-toolchain/bin/alex" -g --latin1 compiler/parser/Lexer.x -o compiler/stage2/build/Lexer.hs "cp" compiler/stage2/build/Lexer.hs sdistprep/ghc/ghc-8.3.20171109/compiler/parser mv sdistprep/ghc/ghc-8.3.20171109/compiler/parser/Lexer.x sdistprep/ghc/ghc-8.3.20171109/compiler/parser/Lexer.x.source "/opt/ghc-stage0-toolchain/bin/happy" -agc --strict compiler/parser/Parser.y -o compiler/stage2/build/Parser.hs "cp" compiler/stage2/build/Parser.hs sdistprep/ghc/ghc-8.3.20171109/compiler/parser mv sdistprep/ghc/ghc-8.3.20171109/compiler/parser/Parser.y sdistprep/ghc/ghc-8.3.20171109/compiler/parser/Parser.y.source "inplace/bin/mkdirhier" utils/hpc/dist-install/build//. "/opt/ghc-stage0-toolchain/bin/happy" -agc --strict utils/hpc/./HpcParser.y -o utils/hpc/dist-install/build/HpcParser.hs unused terminals: 1 "cp" utils/hpc/dist-install/build/HpcParser.hs sdistprep/ghc/ghc-8.3.20171109/utils/hpc/ mv sdistprep/ghc/ghc-8.3.20171109/utils/hpc//HpcParser.y sdistprep/ghc/ghc-8.3.20171109/utils/hpc//HpcParser.y.source "inplace/bin/mkdirhier" utils/genprimopcode/dist/build//. "/opt/ghc-stage0-toolchain/bin/alex" -g utils/genprimopcode/./Lexer.x -o utils/genprimopcode/dist/build/Lexer.hs "cp" utils/genprimopcode/dist/build/Lexer.hs sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode/ mv sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode//Lexer.x sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode//Lexer.x.source "/opt/ghc-stage0-toolchain/bin/happy" -agc --strict utils/genprimopcode/./Parser.y -o utils/genprimopcode/dist/build/Parser.hs "cp" utils/genprimopcode/dist/build/Parser.hs sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode/ mv sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode//Parser.y sdistprep/ghc/ghc-8.3.20171109/utils/genprimopcode//Parser.y.source make[1]: *** No rule to make target 'libraries/Cabal/Cabal/dist- install/build/Distribution/Parsec/Lexer.hs', needed by 'sdist_libraries/Cabal/Cabal_dist-install_Lexer'. Stop. Makefile:161: recipe for target 'sdist-ghc' failed make: *** [sdist-ghc] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 16:02:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 16:02:43 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.716168198eca2629d8ab06275d3e28ef@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): Possibly related: https://github.com/alexbiehl/ghc/commit/f84137a36602a3e5997403283976efdca82f302d -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 16:58:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 16:58:11 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.baafa5f8513083c46de0c22e61f329e3@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 bgamari): > And worse, there doesn't seem to be any reason to expect a size heuristic to produce a proper chain of callstack-aware functions. Ahh, yes, that's a good point. Unlike cost centers, if you miss any link in the chain you lose all locations "above" the missing link. > Well, cost-center stacks require the entire world to have been compiled with -prof, which can be pretty time-consuming. Okay, fair enough. Personally I have configured Cabal to always profiled libraries so the cost generally isn't so high. I suppose if you don't do this switching to profiling would be rather painful, however. It's a shame that profiled code must be so incompatible with unprofiled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 17:41:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 17:41:37 -0000 Subject: [GHC] #14450: GHCi spins forever In-Reply-To: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> References: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> Message-ID: <066.150b96177fb0691af853934e31c9aef6@haskell.org> #14450: GHCi spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | PolyKinds 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 simonpj): I know what is happening here; fix coming -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 18:21:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 18:21:47 -0000 Subject: [GHC] #14460: Can't decompose ghc.exe path Message-ID: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> #14460: Can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC doesn't work Unknown/Multiple | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I downloaded the haskell platform, but when I try to use ghci I get this message: ghc.exe: panic!(the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-mingw32): can't decompose ghc.exe path: "H:\\Programs\\Haskell\\8.2.1\\bin\\ghc.exe" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 21:09:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 21:09:33 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.57d3a9a9a85d8874f17b1780349d9d92@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 simonpj): Indeed, alexbiehl is on the way to implementing the "tantalising point" of comment:89. In a phone call today we agreed * That sharing the parent closure is a good thing to try; and not too hard. * That we should start * A ticket to track progress on it * A wiki page to explain how it all works -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 22:06:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 22:06:44 -0000 Subject: [GHC] #14398: Fail to install haskell platform on Windows In-Reply-To: <045.d86ee14cadb946edd5536f02e4b96185@haskell.org> References: <045.d86ee14cadb946edd5536f02e4b96185@haskell.org> Message-ID: <060.86bc38df68e15b3a146552b57688f41d@haskell.org> #14398: Fail to install haskell platform on Windows -------------------------------------+------------------------------------- Reporter: KAAAsS | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #14168 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Thanks! the trace shows nothing really wrong, I think 8.2 has a memory corruption somewhere that's causing invalid characters to manifest in the strings. I'll have to figure out a way to track it down to verify if it's actually fixed or just happens to work in 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 22:07:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 22:07:23 -0000 Subject: [GHC] #14168: Installing math-functions with GHC-8.2.1 on windows crashed In-Reply-To: <044.4f270678bb008a7a39539de06752d80f@haskell.org> References: <044.4f270678bb008a7a39539de06752d80f@haskell.org> Message-ID: <059.1a087b3cba7b8c7408e6cfefead38392@haskell.org> #14168: Installing math-functions with GHC-8.2.1 on windows crashed ---------------------------------+---------------------------------------- Reporter: Qinka | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: infoneeded => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 22:08:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 22:08:48 -0000 Subject: [GHC] #14168: Installing math-functions with GHC-8.2.1 on windows crashed In-Reply-To: <044.4f270678bb008a7a39539de06752d80f@haskell.org> References: <044.4f270678bb008a7a39539de06752d80f@haskell.org> Message-ID: <059.85b5bd654db3f61394c9e0814ea2fa51@haskell.org> #14168: Installing math-functions with GHC-8.2.1 on windows crashed ---------------------------------+---------------------------------------- Reporter: Qinka | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14398 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * related: => #14398 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 22:13:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 22:13:12 -0000 Subject: [GHC] #14460: Can't decompose ghc.exe path In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.c9c9326701afd08c5be1bcf48df8ee65@haskell.org> #14460: Can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | 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 Phyx-): Did the error msg show up exactly like that? With all `\` in your path replaced by newlines? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 22:35:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 22:35:45 -0000 Subject: [GHC] #14451: Type synonym of type family causes error, error jumps to (fairly) unrelated source location In-Reply-To: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> References: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> Message-ID: <066.8d9164500818abcdd2b145a3f20e1fd7@haskell.org> #14451: Type synonym of type family causes error, error jumps to (fairly) unrelated source location -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType 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 don't think this is #11203. Here's what I think is happening * `Apply`, `Comp`, and `OO` (which I will use instead of the unicode dot symbol) are mutually recursive, and so are kind-checked together. * The first two have CUSKs and so `getInitialKinds` gives them polykinds, thus {{{ kcTyClGroup: initial kinds [r1 :-> ATcTyCon Apply :: forall a b. (a ~> b) -> a -> b, r2 :-> ATcTyCon Comp :: forall k1 k2 k. (k1 ~> k) -> (k2 ~> k1) -> k2 -> k, r4 :-> ATcTyCon OO :: k_aYg[tau:1] -> k_aYh[tau:1] -> k_aYi[tau:1]] }}} Good so far. * But then pathetically, we run over all three declarations, gathering constraints on the kind variables in `OO`. In the end we make `OO` insufficiently polymorphic, giving it kind {{{ OO :: forall b. (b ~> b) -> b -> b }}} whereas it should have kind {{{ OO :: forall a b. (a ~> b) -> a -> b }}} That's stupid: `OO`'s kind should obviously be the same as `Apply`'s What we ''should'' do is exactly what we do for value declarations: * Take the SCC (the group of three declarations) * Remove edges that point to type constructors that have a CUSK * Do a new SCC on this thinned-out graph. * Now `OO` will be first, in a SCC by itself, because `Apply` and `Comp` depend on it, but not vice versa (after removing those edges) * Now kind-check each smaller SCC one by one, generalising each in turn. For bindings you can see the extra SCC analysis being done in `TcBinds.tc_group`. So all we have to do is to replicate this logic for types. Fiddly, perhaps, but not difficult. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 22:43:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 22:43:53 -0000 Subject: [GHC] #11295: Figure out what LLVM passes are fruitful In-Reply-To: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> References: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> Message-ID: <061.946338dd337332e2b6fac6123fd9b65c@haskell.org> #11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: kavon Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.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 kavon): Ben, I think the autotuner is now ready to be applied to Haskell programs: it can successfully tune C/C++ programs, with or without running the output program, to match -O3 in a reasonable time. If it's not too late, I can try to get something in for 8.4. My plan is to pick a few "representative" programs*, tune on each one individually, and see which pass ordering does the best across nofib. If one of them does better than the -Ox passes, we could drop it in GHC pretty easily. What do you think? * Suggestions are welcome here. Infrastructure to tune against the "average" of several programs (using a special objective function) would be ideal, but that infrastructure is not ready yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 23:01:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 23:01:21 -0000 Subject: [GHC] #14460: Can't decompose ghc.exe path In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.85febf15661ed8ca62b9a5c96894067e@haskell.org> #14460: Can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | 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 astert): Oh, no it didn't. That must just be how it formats here. The path has double slashes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 13 23:14:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Nov 2017 23:14:26 -0000 Subject: [GHC] #14460: Can't decompose ghc.exe path In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.7a9b842deffd17edf7425531683e094e@haskell.org> #14460: Can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > I downloaded the haskell platform, but when I try to use ghci I get this > message: > > ghc.exe: panic!(the 'impossible' happened) > (GHC version 8.2.1 for x86_64-unknown-mingw32): > can't decompose ghc.exe path: > "H:\\Programs\\Haskell\\8.2.1\\bin\\ghc.exe" New description: I downloaded the haskell platform, but when I try to use ghci I get this message: {{{ ghc.exe: panic!(the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-mingw32): can't decompose ghc.exe path: "H:\\Programs\\Haskell\\8.2.1\\bin\\ghc.exe" }}} -- Comment (by RyanGlScott): I've code-formatted the panic to make this clearer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 01:52:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 01:52:01 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.df8dadd1836e8366da57d852d5021378@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): So, I guess it has been established that `HasCallStack` cannot be replaced with `-prof` and that it has independent utility, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 10:29:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 10:29:47 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures Message-ID: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 7258 Differential Rev(s): | Wiki Page: NestedClosures -------------------------------------+------------------------------------- Consider [wiki:NestedClosures] and [ticket:7258]; essentially, deeply nested closures exhibit quadratic compiler performance due to the fact that when allocating registers, each nesting level will have the compiler unpack the entire parent closure and then re-pack the variables into the child closure. To solve this, check if the parent closure can be carried along wholesale, and pull variables from there so that the repackaging can be bypassed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 10:30:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 10:30:05 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.cd3459417a6248376fc3fcce0b2842b3@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Comment (by tdammers): Work on this is already being done: https://github.com/alexbiehl/ghc/commit/a5e845eeaac932a9e43a3c2587df1abbd10ba119 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 10:46:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 10:46:41 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.2b8f8e0ec914339541e2904de47cf017@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Changes (by tdammers): * owner: (none) => alexbiehl -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 11:12:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 11:12:49 -0000 Subject: [GHC] #14450: GHCi spins forever In-Reply-To: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> References: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> Message-ID: <066.afe1fdfae7d03a5432aaba8a75dfea04@haskell.org> #14450: GHCi spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | PolyKinds 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 Simon Peyton Jones ): In [changeset:"0a85190312a1de3d300912051309b94589c08683/ghc" 0a851903/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0a85190312a1de3d300912051309b94589c08683" Fix a TyVar bug in the flattener A year ago I gave up on trying to rigorously separate TyVars from TcTyVars, and instead allowed TyVars to appear rather more freely in types examined by the constraint solver: commit 18d0bdd3848201882bae167e3b15fd797d217e93 Author: Simon Peyton Jones Date: Wed Nov 23 16:00:00 2016 +0000 Allow TyVars in TcTypes See Note [TcTyVars in the typechecker] in TcType. However, TcFlatten.flatten_tyvar1 turned out to treat a TyVar specially, and implicitly assumed that it could not have an equality constraint in the inert set. Wrong! This caused Trac #14450. Fortunately it is easily fixed, by deleting code. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 11:20:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 11:20:52 -0000 Subject: [GHC] #14450: GHCi spins forever In-Reply-To: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> References: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> Message-ID: <066.b6a0960ef42fcf9408d38b97fac5741c@haskell.org> #14450: GHCi spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: TypeInType, | PolyKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | polykinds/T14450 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T14450 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 11:38:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 11:38:45 -0000 Subject: [GHC] #14462: deriving on associated data types fails to find constraints Message-ID: <044.580acd28e55c0dcc1b5451adfc6c6571@haskell.org> #14462: deriving on associated data types fails to find constraints -------------------------------------+------------------------------------- Reporter: mf825 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple associated types, deriving | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeFamilies, UndecidableInstances #-} class D a where data DT a class C a where data CT a instance (D a, Eq (DT a)) => C (Maybe a) where data CT (Maybe a) = CTMaybe (DT a) deriving (Eq) {- $ stack --resolver=nightly-2017-10-20 exec -- ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.1 $ stack --resolver=nightly-2017-10-20 exec -- ghci Main.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help (0.00 secs, 0 bytes) (0.00 secs, 0 bytes) (0.00 secs, 0 bytes) (0.00 secs, 0 bytes) (0.00 secs, 0 bytes) (0.00 secs, 0 bytes) (0.00 secs, 0 bytes) (0.00 secs, 0 bytes) Loaded GHCi configuration from /home/mf/.ghci [1 of 1] Compiling Main ( Main.hs, interpreted ) Main.hs:7:48: error: • No instance for (Eq (DT a)) arising from the first field of ‘CTMaybe’ (type ‘DT a’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Eq (CT (Maybe a))) | 7 | data CT (Maybe a) = CTMaybe (DT a) deriving (Eq) | ^^ Failed, 0 modules loaded. (0.03 secs,) Prelude> -- if i remove the offending @deriving@ clause above and add this line, everything is fine. -- use -XFlexibleInstances -XStandaloneDeriving for this. deriving instance Eq (DT a) => Eq (CT (Maybe a)) -} }}} checked on linux with ghc8.0.2 and 8.2.1. thanks! and sorry if i've missed a previous report covering this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 11:47:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 11:47:34 -0000 Subject: [GHC] #14462: deriving on associated data types fails to find constraints In-Reply-To: <044.580acd28e55c0dcc1b5451adfc6c6571@haskell.org> References: <044.580acd28e55c0dcc1b5451adfc6c6571@haskell.org> Message-ID: <059.09d68946ab43cf8cf0423081e2836223@haskell.org> #14462: deriving on associated data types fails to find constraints -------------------------------------+------------------------------------- Reporter: mf825 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeFamilies, Resolution: | associated types, deriving 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): Looks ok to me. There's no reason that the context of the `C`-instance decl for `Maybe a` should be the same as that of the `Eq`-instance decl for `CT (Maybe a)`. As the message says, a standalone deriving declaration should do the job nicely. Did you try that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 12:14:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 12:14:31 -0000 Subject: [GHC] #14462: deriving on associated data types fails to find constraints In-Reply-To: <044.580acd28e55c0dcc1b5451adfc6c6571@haskell.org> References: <044.580acd28e55c0dcc1b5451adfc6c6571@haskell.org> Message-ID: <059.9e98a16c0f9733b94bf8907f785b8980@haskell.org> #14462: deriving on associated data types fails to find constraints -------------------------------------+------------------------------------- Reporter: mf825 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeFamilies, Resolution: | associated types, deriving 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 mf825): thanks for the quick feedback! i guess what confused me was my assumption that the instance decl context should be also the context of the data decl, but perhaps there is some good reason not to have that. sorry, my mistake. please close this issue. cheers! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 12:15:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 12:15:18 -0000 Subject: [GHC] #14462: deriving on associated data types fails to find constraints In-Reply-To: <044.580acd28e55c0dcc1b5451adfc6c6571@haskell.org> References: <044.580acd28e55c0dcc1b5451adfc6c6571@haskell.org> Message-ID: <059.af3e6ef1737cbced81f7e701c0a5c3a1@haskell.org> #14462: deriving on associated data types fails to find constraints -------------------------------------+------------------------------------- Reporter: mf825 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeFamilies, Resolution: fixed | associated types, deriving 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 mf825): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 13:25:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 13:25:09 -0000 Subject: [GHC] #14463: Pattern synonym for appliation Message-ID: <051.a7346e93cbdc5329b282c53c99b94728@haskell.org> #14463: Pattern synonym for appliation -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Does this make sense {{{#!hs pattern f :$ x = f x }}} where `Just :$ False` is the same as the pattern `Just False`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 14:25:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 14:25:34 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.9f5e2c7c3a9ecccef443d7d840d6617a@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 gridaphobe): Replying to [comment:36 saurabhnanda]: > So, I guess it has been established that `HasCallStack` cannot be replaced with `-prof` and that it has independent utility, right? `HasCallStack` definitely has independent utility, yes. The question Ben is raising is whether this proposed flag to add `HasCallStack` constraints throughout a module has independent utility. I think the answer is still yes, as I argued above, but it's admittedly less obvious than the original use-case for `HasCallStack` (opt-in source locations on a per-function basis). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 15:45:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 15:45:28 -0000 Subject: [GHC] #4815: Instance constraints should be used when deriving on associated data types In-Reply-To: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> References: <053.c441f4244b7cbf5f776a3f11a710bc57@haskell.org> Message-ID: <068.f944e6b3c39fd97b67d84a37aff91044@haskell.org> #4815: Instance constraints should be used when deriving on associated data types -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: (none) Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 6.12.3 Resolution: invalid | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12863, #14462 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid * related: #12863 => #12863, #14462 Comment: I'm going to close this, since: 1. The consensus appears to be that this isn't desirable. 2. We're operating under this consensus in other tickets (see #14462, for example). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 15:47:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 15:47:16 -0000 Subject: [GHC] #14463: Pattern synonym for appliation In-Reply-To: <051.a7346e93cbdc5329b282c53c99b94728@haskell.org> References: <051.a7346e93cbdc5329b282c53c99b94728@haskell.org> Message-ID: <066.481be8c8bf2db3eb917db3b86a961bca@haskell.org> #14463: Pattern synonym for appliation -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): > Does this make sense It certainly doesn't in my mind. You'd have to allow this sort of pattern: {{{#!hs foo (f x) = ... }}} To which I can't ascribe any sort of meaningful semantics at the value level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 16:36:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 16:36:03 -0000 Subject: [GHC] #14462: deriving on associated data types fails to find constraints In-Reply-To: <044.580acd28e55c0dcc1b5451adfc6c6571@haskell.org> References: <044.580acd28e55c0dcc1b5451adfc6c6571@haskell.org> Message-ID: <059.d6d4199564f134b5596cfada071a3af3@haskell.org> #14462: deriving on associated data types fails to find constraints -------------------------------------+------------------------------------- Reporter: mf825 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: TypeFamilies, Resolution: fixed | associated types, deriving 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): See also #4815 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 19:42:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 19:42:52 -0000 Subject: [GHC] #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) In-Reply-To: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> References: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> Message-ID: <064.00470071db2d0f84a8fe9a795fe56efe@haskell.org> #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) -------------------------------------+------------------------------------- Reporter: carlostome | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: profiler Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14006, #11645 | Differential Rev(s): Phab:D4184 Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * status: new => patch * differential: => Phab:D4184 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 20:49:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 20:49:06 -0000 Subject: [GHC] #14464: Adjust AltCon Ord instance to match linter requirements. Message-ID: <047.6247340d9480dc11fbdad08efa8e8bc5@haskell.org> #14464: Adjust AltCon Ord instance to match linter requirements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 Ord instance for AltCon which is incompatible with the Core Linters requirements. Updating it to match the linters requirement seems useful as it allows easy sorting of alternatives. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 20:49:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 20:49:22 -0000 Subject: [GHC] #14464: Adjust AltCon Ord instance to match linter requirements. In-Reply-To: <047.6247340d9480dc11fbdad08efa8e8bc5@haskell.org> References: <047.6247340d9480dc11fbdad08efa8e8bc5@haskell.org> Message-ID: <062.14e1e32751fa3de7759299ec9df8ef94@haskell.org> #14464: Adjust AltCon Ord instance to match linter requirements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 AndreasK): * owner: (none) => AndreasK -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 20:53:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 20:53:08 -0000 Subject: [GHC] #14463: Pattern synonym for appliation In-Reply-To: <051.a7346e93cbdc5329b282c53c99b94728@haskell.org> References: <051.a7346e93cbdc5329b282c53c99b94728@haskell.org> Message-ID: <066.49a389530709dec1d32ff76cc8f6c864@haskell.org> #14463: Pattern synonym for appliation -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | 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 Iceland_jack): * status: new => closed * resolution: => invalid Comment: Why like this of course {{{#!hs destruct :: Either a a -> (String, a) destruct (Left a) = ("Left", a) destruct (Right a) = ("Right", a) pattern (:$) :: String -> a -> Either a a pattern f :$ x <- (destruct -> (f, x)) }}} ;) I agree that the idea is not meaningful, closing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 22:02:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 22:02:30 -0000 Subject: [GHC] #14465: Performance of Natural Message-ID: <047.dbabb1127ee36a01bf1bf2eb91b6c532@haskell.org> #14465: Performance of Natural -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Recently I tried to use `Natural` instead of `Integer` in one of my projects. I expected no difference or even a minor performance boost (since `Natural` does not have to worry about a sign). But in fact it caused a slowdown. A constant of type `Integer` will be evaluated to a low-level representation (`S#` / `Jp#` / `Jn#`) during `CorePrep` stage. Nothing of this kind happens to constant values of type `Natural`: {{{#!hs import Numeric.Natural one :: Natural one = fromInteger 1 }}} is translated to {{{#!hs one1 :: Integer one1 = 1 -- will be converted by CorePrep to S# 1# one :: Natural one = case one1 of { S# i#_a2c6 -> case tagToEnum# (>=# i#_a2c6 0#) of { False -> underflowError; True -> NatS# (int2Word# i#_a2c6) }; Jp# dt_a2cg -> case uncheckedIShiftRL# (sizeofByteArray# dt_a2cg) 3# of { __DEFAULT -> case sizeofByteArray# dt_a2cg of { __DEFAULT -> NatJ# dt_a2cg; 0# -> underflowError }; 1# -> case indexWordArray# dt_a2cg 0# of wild2_a2ck { __DEFAULT -> NatS# wild2_a2ck } }; Jn# ipv_a2cn -> underflowError } }}} This is not bad itself, if `one` is a top-level definition. At the end of the day a thunk will be replaced by its value, computed exactly once. But suppose we have written {{{#!hs import Numeric.Natural plusOne :: Natural -> Natural plusOne n = n + 1 }}} The corresponding Core looks this way: {{{#!hs plusOne :: Natural -> Natural plusOne = \ (n_auS :: Natural) -> case 1 of { S# i#_a2dA -> case tagToEnum# (>=# i#_a2dA 0#) of { False -> case underflowError of wild2_00 { }; True -> plusNatural n_auS (NatS# (int2Word# i#_a2dA)) }; Jp# dt_a2dI -> case uncheckedIShiftRL# (sizeofByteArray# dt_a2dI) 3# of { __DEFAULT -> case sizeofByteArray# dt_a2dI of { __DEFAULT -> plusNatural n_auS (NatJ# dt_a2dI); 0# -> case underflowError of wild4_00 { } }; 1# -> case indexWordArray# dt_a2dI 0# of wild2_a2dM { __DEFAULT -> plusNatural n_auS (NatS# wild2_a2dM) } }; Jn# ipv_a2dP -> case underflowError of wild1_00 { } } }}} It looks expensive to pattern match `1` repeatedly, at every call to `plusOne`. Another deficiency of `Natural` is that no constant folding is done. Even `2 * 2` results in 50 lines of Core: {{{#!hs twoTimesTwo2 :: Integer twoTimesTwo2 = 2 twoTimesTwo1 :: Natural twoTimesTwo1 = case twoTimesTwo2 of { S# i#_a2u3 -> case tagToEnum# (>=# i#_a2u3 0#) of { False -> underflowError; True -> NatS# (int2Word# i#_a2u3) }; Jp# dt_a2ub -> case uncheckedIShiftRL# (sizeofByteArray# dt_a2ub) 3# of { __DEFAULT -> case sizeofByteArray# dt_a2ub of { __DEFAULT -> NatJ# dt_a2ub; 0# -> underflowError }; 1# -> case indexWordArray# dt_a2ub 0# of wild2_a2uf { __DEFAULT -> NatS# wild2_a2uf } }; Jn# ipv_a2ui -> underflowError } twoTimesTwo :: Natural twoTimesTwo = case twoTimesTwo2 of { S# i#_a2u3 -> case tagToEnum# (>=# i#_a2u3 0#) of { False -> case underflowError of wild2_00 { }; True -> $fNumNatural_$c* twoTimesTwo1 (NatS# (int2Word# i#_a2u3)) }; Jp# dt_a2ub -> case uncheckedIShiftRL# (sizeofByteArray# dt_a2ub) 3# of { __DEFAULT -> case sizeofByteArray# dt_a2ub of { __DEFAULT -> $fNumNatural_$c* twoTimesTwo1 (NatJ# dt_a2ub); 0# -> case underflowError of wild4_00 { } }; 1# -> case indexWordArray# dt_a2ub 0# of wild2_a2uf { __DEFAULT -> $fNumNatural_$c* twoTimesTwo1 (NatS# wild2_a2uf) } }; Jn# ipv_a2ui -> case underflowError of wild1_00 { } } }}} This is not surprising, since constant folding of `Integer` works only due to a special Core literal `LitInteger` and a set of hardcoded `PrelRules.builtinIntegerRules` (and `NOINLINE` pragmas in `GHC.Integer.Type`). ---- Is it reasonable to make `Natural` a first-class Core citizen? I suppose a new `LitNatural` node and decent amount of copy-paste will do. Or, possibly, we may reuse `LitInteger Integer Type` with appropriate `Type` to avoid some duplication of code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 22:57:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 22:57:35 -0000 Subject: [GHC] #14464: Adjust AltCon Ord instance to match linter requirements. In-Reply-To: <047.6247340d9480dc11fbdad08efa8e8bc5@haskell.org> References: <047.6247340d9480dc11fbdad08efa8e8bc5@haskell.org> Message-ID: <062.16adc3d574285823fb8a9a7300516d8a@haskell.org> #14464: Adjust AltCon Ord instance to match linter requirements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.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): Phab:D4198 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: new => patch * differential: => Phab:D4198 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 23:42:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 23:42:29 -0000 Subject: [GHC] #14466: Error while installing codeworld-api Message-ID: <048.2e267e051a4138faf652c772c20b3f06@haskell.org> #14466: Error while installing codeworld-api -------------------------------------+------------------------------------- Reporter: Zalathorm | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- C:\Users\****>cabal install codeworld-api Resolving dependencies... Configuring codeworld-api-0.2.1.0... Building codeworld-api-0.2.1.0... Failed to install codeworld-api-0.2.1.0 Build log ( C:\Users\****\AppData\Roaming\cabal\logs\ghc-8.2.1\codeworld- api-0.2.1.0-FP1wjOCq6YC5GIs4ve2sRp.log ): Preprocessing library for codeworld-api-0.2.1.0.. Building library for codeworld-api-0.2.1.0.. [1 of 6] Compiling CodeWorld.Color ( src\CodeWorld\Color.hs, dist\build\CodeWorld\Color.o ) [2 of 6] Compiling CodeWorld.Picture ( src\CodeWorld\Picture.hs, dist\build\CodeWorld\Picture.o ) [3 of 6] Compiling CodeWorld.Event ( src\CodeWorld\Event.hs, dist\build\CodeWorld\Event.o ) [4 of 6] Compiling CodeWorld.CollaborationUI ( src\CodeWorld\CollaborationUI.hs, dist\build\CodeWorld\CollaborationUI.o ) ghc.exe: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-mingw32): runtimeRepPrimRep typePrimRep (r_abQP :: TYPE rep_abQO) rep_abQO Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler\simplStg\RepType.hs:360:5 in ghc:RepType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Leaving directory 'C:\Users\****\AppData\Local\Temp\cabal-tmp-5456 \codeworld-api-0.2.1.0' cabal: Error: some packages failed to install: codeworld-api-0.2.1.0-FP1wjOCq6YC5GIs4ve2sRp failed during the building phase. The exception was: ExitFailure 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 23:51:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 23:51:34 -0000 Subject: [GHC] #14465: Performance of Natural In-Reply-To: <047.dbabb1127ee36a01bf1bf2eb91b6c532@haskell.org> References: <047.dbabb1127ee36a01bf1bf2eb91b6c532@haskell.org> Message-ID: <062.45e5add550aaa827be8c8ab7437ebdd9@haskell.org> #14465: Performance of Natural -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14170 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14170 Comment: Indeed, this discrepancy has been noted in #14170 (so I'll mark this ticket as a duplicate). See https://ghc.haskell.org/trac/ghc/ticket/14170#comment:2 and https://ghc.haskell.org/trac/ghc/ticket/14170#comment:3 for a discussion on how one might fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 23:55:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 23:55:00 -0000 Subject: [GHC] #14466: Error while installing codeworld-api In-Reply-To: <048.2e267e051a4138faf652c772c20b3f06@haskell.org> References: <048.2e267e051a4138faf652c772c20b3f06@haskell.org> Message-ID: <063.d765790774561f87b03409e5d39721f4@haskell.org> #14466: Error while installing codeworld-api -------------------------------------+------------------------------------- Reporter: Zalathorm | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.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 RyanGlScott): * status: new => infoneeded Old description: > C:\Users\****>cabal install codeworld-api > Resolving dependencies... > Configuring codeworld-api-0.2.1.0... > Building codeworld-api-0.2.1.0... > Failed to install codeworld-api-0.2.1.0 > Build log ( C:\Users\****\AppData\Roaming\cabal\logs\ghc-8.2.1\codeworld- > api-0.2.1.0-FP1wjOCq6YC5GIs4ve2sRp.log ): > Preprocessing library for codeworld-api-0.2.1.0.. > Building library for codeworld-api-0.2.1.0.. > [1 of 6] Compiling CodeWorld.Color ( src\CodeWorld\Color.hs, > dist\build\CodeWorld\Color.o ) > [2 of 6] Compiling CodeWorld.Picture ( src\CodeWorld\Picture.hs, > dist\build\CodeWorld\Picture.o ) > [3 of 6] Compiling CodeWorld.Event ( src\CodeWorld\Event.hs, > dist\build\CodeWorld\Event.o ) > [4 of 6] Compiling CodeWorld.CollaborationUI ( > src\CodeWorld\CollaborationUI.hs, dist\build\CodeWorld\CollaborationUI.o > ) > ghc.exe: panic! (the 'impossible' happened) > (GHC version 8.2.1 for x86_64-unknown-mingw32): > runtimeRepPrimRep > typePrimRep (r_abQP :: TYPE rep_abQO) > rep_abQO > Call stack: > CallStack (from HasCallStack): > prettyCurrentCallStack, called at > compiler\utils\Outputable.hs:1133:58 in ghc:Outputable > callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in > ghc:Outputable > pprPanic, called at compiler\simplStg\RepType.hs:360:5 in > ghc:RepType > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > cabal: Leaving directory 'C:\Users\****\AppData\Local\Temp\cabal-tmp-5456 > \codeworld-api-0.2.1.0' > cabal: Error: some packages failed to install: > codeworld-api-0.2.1.0-FP1wjOCq6YC5GIs4ve2sRp failed during the building > phase. > The exception was: > ExitFailure 1 New description: {{{ C:\Users\****>cabal install codeworld-api Resolving dependencies... Configuring codeworld-api-0.2.1.0... Building codeworld-api-0.2.1.0... Failed to install codeworld-api-0.2.1.0 Build log ( C:\Users\****\AppData\Roaming\cabal\logs\ghc-8.2.1\codeworld- api-0.2.1.0-FP1wjOCq6YC5GIs4ve2sRp.log ): Preprocessing library for codeworld-api-0.2.1.0.. Building library for codeworld-api-0.2.1.0.. [1 of 6] Compiling CodeWorld.Color ( src\CodeWorld\Color.hs, dist\build\CodeWorld\Color.o ) [2 of 6] Compiling CodeWorld.Picture ( src\CodeWorld\Picture.hs, dist\build\CodeWorld\Picture.o ) [3 of 6] Compiling CodeWorld.Event ( src\CodeWorld\Event.hs, dist\build\CodeWorld\Event.o ) [4 of 6] Compiling CodeWorld.CollaborationUI ( src\CodeWorld\CollaborationUI.hs, dist\build\CodeWorld\CollaborationUI.o ) ghc.exe: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-mingw32): runtimeRepPrimRep typePrimRep (r_abQP :: TYPE rep_abQO) rep_abQO Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler\simplStg\RepType.hs:360:5 in ghc:RepType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Leaving directory 'C:\Users\****\AppData\Local\Temp\cabal-tmp-5456 \codeworld-api-0.2.1.0' cabal: Error: some packages failed to install: codeworld-api-0.2.1.0-FP1wjOCq6YC5GIs4ve2sRp failed during the building phase. The exception was: ExitFailure 1 }}} -- Comment: I think there is an extremely high chance that this is a duplicate of #14393, but I don't have a GHCJS installation on hand to test this. Can you try building `codeworld-api` with [https://downloads.haskell.org/~ghc/8.2.2-rc3/ghc-8.2.1.20171108-x86_64 -unknown-mingw32.tar.xz GHC 8.2.2-rc3] and see if that resolves the issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 14 23:56:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Nov 2017 23:56:31 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.dae3e248a0cba87118edcdf610fa531d@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.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 Bodigrim): * cc: Bodigrim (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 00:32:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 00:32:43 -0000 Subject: [GHC] #14466: Error while installing codeworld-api In-Reply-To: <048.2e267e051a4138faf652c772c20b3f06@haskell.org> References: <048.2e267e051a4138faf652c772c20b3f06@haskell.org> Message-ID: <063.8b80864b23c285a27218e1586e15b88b@haskell.org> #14466: Error while installing codeworld-api -------------------------------------+------------------------------------- Reporter: Zalathorm | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.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 nomeata): Why do you need GHCJS? This seems to be normal ghc compiling codeoworld- api. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 03:21:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 03:21:14 -0000 Subject: [GHC] #14460: Can't decompose ghc.exe path In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.ec508b3fd437e5d3c1d5d0f377cd1ebc@haskell.org> #14460: Can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | 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 Phyx-): Ah ok thanks, so does `"H:\\Programs\\Haskell\\8.2.1\\lib` exist? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 04:50:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 04:50:55 -0000 Subject: [GHC] #14460: Can't decompose ghc.exe path In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.d55530fcc8aa694b7d85cbd05a176128@haskell.org> #14460: Can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | 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 astert): Yes, it does. That folder contains ghc.exe, among other things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 05:08:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 05:08:24 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.11acc11f7563d7d7af08569b374bf5cd@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 saurabhnanda): Is there **any way** to enable callstacks without recompiling all your (transitive) dependencies? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 08:08:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 08:08:28 -0000 Subject: [GHC] #14465: Performance of Natural In-Reply-To: <047.dbabb1127ee36a01bf1bf2eb91b6c532@haskell.org> References: <047.dbabb1127ee36a01bf1bf2eb91b6c532@haskell.org> Message-ID: <062.cc28509dca8cc0e3a78d3fbbc21ce733@haskell.org> #14465: Performance of Natural -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14170 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): I have to admit that I knew about this every since GHC 7.10 came out, but I never got around to fix this one :-/ This is also related to the lack of support of `-Woverflowed-literals` for `Natural`s which was blocked on making GHC gnostic of the `Natural` type at the Core level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 10:06:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 10:06:31 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.9be8d387047c3097b5f22da8db38573e@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Comment (by alexbiehl): Transforming the free variables in the codegen (as done in the mentioned patch) remains hairy. I have another plan: I will introduce a new `data GenStgFreeVar occ = StgFreeVar occ [occ]` type and calculate the sharing in CoreToStg as we have all the relevant data available and in good shape anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 10:17:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 10:17:00 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.d91723e9e464ea2e782f35fec0ffec77@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Comment (by simonpj): > I have another plan: I will introduce a new data GenStgFreeVar occ = StgFreeVar occ [occ] type and calculate the sharing in CoreToStg as we have all the relevant data available and in good shape anyway. I think that's a great plan: see [wiki:NestedClosures] under "Implementation". If you could describe the moving parts of your plan in the wiki page, it'd help us to offer you support and feedback. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 10:55:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 10:55:52 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.e60aac39aed18b0cebb6b72eff4d2137@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Comment (by alexbiehl): Replying to [comment:4 simonpj]: > I think that's a great plan: see [wiki:NestedClosures] under "Implementation". Ups, I didn't see that! I have another thing, somewhat related: If we find something like {{{ case e of x { T a b c -> let [a b c] f = \[] -> } }}} Why not make it {{{ case e of x { -- evaluate e to not change strictness T _ _ _ -> let [x] f = \[] -> case x of T a b c -> ... } }}} This could even be done at Core level I suppose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 11:03:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 11:03:46 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.767d320b2da78f8df7427acf4c39ff1f@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Comment (by simonpj): Yes you could do that in Core, but the simplifier would immediately undo it by eliminating the inner case. However, in our proposed STG-level transformation, I think we could indeed transform {{{ case e of x { T a b c -> let [a b c] f = \[] -> ... } }}} to {{{ case e of x { T _ _ _ -> let [x{a,b,c}] f = \[] -> ... } }}} using the notation on the wiki page. I'm beginning to think that it might be easier to do this free-var-finding stuff as a STG-to-STG pass with a single purpose, rather than as part of Core-to-STG. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 11:06:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 11:06:41 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.1c6106695159cd762c997d9ed720326c@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Comment (by alexbiehl): Replying to [comment:6 simonpj]: > I'm beginning to think that it might be easier to do this free-var- finding stuff as a STG-to-STG pass with a single purpose, rather than as part of Core-to-STG. Seems reasonable. I will take that in consideration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 13:57:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 13:57:31 -0000 Subject: [GHC] #14466: Error while installing codeworld-api In-Reply-To: <048.2e267e051a4138faf652c772c20b3f06@haskell.org> References: <048.2e267e051a4138faf652c772c20b3f06@haskell.org> Message-ID: <063.49723b583fb9a2b55265f1c58c72dfe6@haskell.org> #14466: Error while installing codeworld-api -------------------------------------+------------------------------------- Reporter: Zalathorm | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => closed * resolution: => duplicate * related: => #14393 Comment: Ah, my bad. I saw the list of dependencies on the [http://hackage.haskell.org/package/codeworld-api-0.2.1.0 Hackage page] and mistakenly assumed that `ghcjs-base` was a mandatory dependency (when in reality, it's an optional dependency guarded behind a `.cabal` flag). I just installed `codeworld-api-0.2.1.0` with GHC 8.2.2-rc3 without seeing this panic, so I think it's safe to conclude that this is a duplicate of #14393. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 15:20:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 15:20:13 -0000 Subject: [GHC] #14467: Support HasCallStack for calls to panic Message-ID: <047.e62d0844ad019ed17459f279733f58a5@haskell.org> #14467: Support HasCallStack for calls to panic -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: GHC API | Version: 8.2.1 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 far as I can tell `panic` only reports cost center callstacks currently. It would be useful to include information provided by HasCallStack if available as well. When using the GHC API (or hacking on GHC itself) this would be a convenient way to get more information about what lead to an error that triggers `panic` in a different part of the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 16:18:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 16:18:16 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.f83817895d8b1c12e3f44fb24f4cbdaf@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13497, 13525 | Blocking: Related Tickets: #12912, #13525 | Differential Rev(s): Phab:D42 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Some more trouble on Windows (also for `-threaded`): If the FD is a [https://github.com/ghc/ghc/blob/ghc-8.2.1-release/libraries/base/cbits/inputReady.c#L109 FILE_TYPE_CHAR], then the implementation of `ccall interruptible` ([https://downloads.haskell.org/~ghc/8.2.1/docs/html/users_guide/ffi- chap.html#interruptible-foreign-calls see here]) via `CancelSynchronousIo` doesn't seem to kill the [https://github.com/nh2/ghc/blob/bug-8684 -interruptible-hWaitForInput/libraries/base/cbits/inputReady.c#L306 WaitForSingleObject()] invocation. Unfortunately, the call to [https://github.com/ghc/ghc/blob/ghc-8.2.1-release/rts/win32/OSThreads.c#L569 CancelSynchronousIo(), here named pCSIO()], does not actually check the return value of [https://msdn.microsoft.com/en- us/library/windows/desktop/aa363794(v=vs.85).aspx the function], which returns a `BOOL success`. > If this function cannot find a request to cancel, the return value is 0 (zero), and `GetLastError` returns `ERROR_NOT_FOUND`. In my case, when logging it, I see it returns error code 1168, which is `ERROR_NOT_FOUND`, so apparently nothing was cancelled. As a result, my example program from the issue description runs for 5 seconds instead of one. With a bit more instrumentation, I get this: {{{ fdReady called with msecs = 5000 calling WaitForSingleObject calling pCSIO pCSIO ret 0 pCSIO error: 1168 WaitForSingleObject rc 258 (WAIT_TIMEOUT) }}} After 1 second, as expected, it's `calling pCSIO`, but it doesn't cancel anything due to the error, so after 5 seconds `WaitForSingleObject rc 258 (WAIT_TIMEOUT)` happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 16:23:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 16:23:59 -0000 Subject: [GHC] #14468: Why does alanz's branch blow up GHC's heap? Message-ID: <046.be390aa8ac1f4abd294d2b3b0f58b57c@haskell.org> #14468: Why does alanz's branch blow up GHC's heap? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- alanz mentioned that moving all of GHC's `Data` instances [[https://git.haskell.org/ghc.git/blob/12028239b597e17fb3f3734c6b494e127be58e0c:/compiler/hsSyn/HsInstances.hs|instances]] to a new module causes the stage1 compile to run out of memory during compilation (he has 8 GB of memory). This is rather suspicious as this module isn't terribly large. IIRC typechecking time may be non-linear in program size, but I don't see why it would be non-linear in space. Investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 17:45:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 17:45:04 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.d8d2c7316c8d0f542d4101299a3e50fc@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13497, 13525 | Blocking: Related Tickets: #12912, #13525 | Differential Rev(s): Phab:D42 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I've augmented my debugging output by the Windows thread ID [https://github.com/ghc/ghc/blob/ghc-8.2.1-release/rts/win32/OSThreads.c#L558 here] and with `GetCurrentThreadId()`: {{{ fdReady called with msecs = 5000 calling WaitForSingleObject in windows thread id 0000000000000b14 calling pCSIO(thread id 0000000000000b14) pCSIO ret 0 pCSIO error: 1168 WaitForSingleObject rc 258 (WAIT_TIMEOUT) }}} Looks like the thread IDs are the same, so I currently have no idea why `pCSIO()` running wouldn't switftly terminate the `WaitForSingleObject()` on this `FILE_TYPE_CHAR` FD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 19:46:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 19:46:12 -0000 Subject: [GHC] #14468: Why does alanz's branch blow up GHC's heap? In-Reply-To: <046.be390aa8ac1f4abd294d2b3b0f58b57c@haskell.org> References: <046.be390aa8ac1f4abd294d2b3b0f58b57c@haskell.org> Message-ID: <061.ab3bcb7ac18213eaaaf40548410859cf@haskell.org> #14468: Why does alanz's branch blow up GHC's heap? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.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 bgamari): Perhaps unsurprisingly, the dominant contribution here is typechecking, {{{ *** Checking old interface for HsInstances (use -ddump-hi-diffs for more details): *** Parser [HsInstances]: !!! Parser [HsInstances]: finished in 4.90 milliseconds, allocated 9.166 megabytes *** Renamer/typechecker [HsInstances]: !!! Renamer/typechecker [HsInstances]: finished in 48430.88 milliseconds, allocated 59998.701 megabytes *** Desugar [HsInstances]: Result size of Desugar (after optimization) = {terms: 39,619, types: 309,762, coercions: 4,274,106, joins: 0/3,281} !!! Desugar [HsInstances]: finished in 17066.61 milliseconds, allocated 21449.018 megabytes *** Simplifier [HsInstances]: Result size of Simplifier iteration=1 = {terms: 61,148, types: 351,421, coercions: 238,159, joins: 0/3,212} Result size of Simplifier iteration=2 = {terms: 59,333, types: 350,264, coercions: 242,742, joins: 0/2,475} Result size of Simplifier iteration=3 = {terms: 58,354, types: 345,841, coercions: 241,068, joins: 0/2,446} Result size of Simplifier iteration=4 = {terms: 58,338, types: 345,742, coercions: 240,892, joins: 0/2,444} Result size of Simplifier = {terms: 58,338, types: 345,742, coercions: 240,892, joins: 0/2,444} !!! Simplifier [HsInstances]: finished in 3464.16 milliseconds, allocated 5298.698 megabytes *** Specialise [HsInstances]: Result size of Specialise = {terms: 63,565, types: 358,072, coercions: 242,946, joins: 0/2,422} !!! Specialise [HsInstances]: finished in 366.65 milliseconds, allocated 806.110 megabytes *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [HsInstances]: Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 72,114, types: 387,785, coercions: 242,946, joins: 0/2,790} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [HsInstances]: finished in 665.25 milliseconds, allocated 927.697 megabytes *** Simplifier [HsInstances]: Result size of Simplifier iteration=1 = {terms: 72,811, types: 394,019, coercions: 243,374, joins: 0/2,887} Result size of Simplifier iteration=2 = {terms: 70,244, types: 394,237, coercions: 243,092, joins: 0/2,782} Result size of Simplifier iteration=3 = {terms: 70,207, types: 395,136, coercions: 243,092, joins: 0/2,760} Result size of Simplifier = {terms: 70,207, types: 395,136, coercions: 243,092, joins: 0/2,760} !!! Simplifier [HsInstances]: finished in 2800.81 milliseconds, allocated 3389.853 megabytes *** Simplifier [HsInstances]: Result size of Simplifier iteration=1 = {terms: 69,365, types: 393,057, coercions: 243,092, joins: 9/2,769} Result size of Simplifier iteration=2 = {terms: 69,317, types: 393,038, coercions: 243,092, joins: 0/2,760} Result size of Simplifier iteration=3 = {terms: 69,310, types: 393,039, coercions: 243,092, joins: 0/2,770} Result size of Simplifier = {terms: 69,290, types: 393,029, coercions: 243,092, joins: 0/2,760} !!! Simplifier [HsInstances]: finished in 2498.60 milliseconds, allocated 3181.271 megabytes *** Simplifier [HsInstances]: Result size of Simplifier iteration=1 = {terms: 86,688, types: 407,268, coercions: 243,089, joins: 292/3,052} lt size of Simplifier = {terms: 86,688, types: 407,268, coercions: 243,089, joins: 292/3,052} !!! Simplifier [HsInstances]: finished in 1482.55 milliseconds, allocated 1822.554 megabytes *** Float inwards [HsInstances]: Result size of Float inwards = {terms: 86,688, types: 407,268, coercions: 243,089, joins: 292/3,052} !!! Float inwards [HsInstances]: finished in 257.39 milliseconds, allocated 492.612 megabytes *** Called arity analysis [HsInstances]: Result size of Called arity analysis = {terms: 86,688, types: 407,268, coercions: 243,089, joins: 292/3,052} !!! Called arity analysis [HsInstances]: finished in 857.47 milliseconds, allocated 1821.950 megabytes *** Simplifier [HsInstances]: Result size of Simplifier iteration=1 = {terms: 86,688, types: 407,268, coercions: 243,089, joins: 292/3,052} Result size of Simplifier = {terms: 86,688, types: 407,268, coercions: 243,089, joins: 292/3,052} !!! Simplifier [HsInstances]: finished in 6407.60 milliseconds, allocated 1816.619 megabytes *** Demand analysis [HsInstances]: Result size of Demand analysis = {terms: 86,688, types: 407,268, coercions: 243,089, joins: 292/3,052} !!! Demand analysis [HsInstances]: finished in 7202.07 milliseconds, allocated 9270.744 megabytes *** Worker Wrapper binds [HsInstances]: Result size of Worker Wrapper binds = {terms: 90,308, types: 415,860, coercions: 243,120, joins: 292/3,610} !!! Worker Wrapper binds [HsInstances]: finished in 91.28 milliseconds, allocated 42.636 megabytes *** Simplifier [HsInstances]: Result size of Simplifier iteration=1 = {terms: 90,034, types: 416,359, coercions: 243,643, joins: 314/3,097} Result size of Simplifier iteration=2 = {terms: 88,163, types: 411,674, coercions: 243,143, joins: 292/3,055} Result size of Simplifier iteration=3 = {terms: 88,115, types: 411,518, coercions: 243,081, joins: 292/3,052} Result size of Simplifier = {terms: 88,115, types: 411,518, coercions: 243,081, joins: 292/3,052} !!! Simplifier [HsInstances]: finished in 3032.09 milliseconds, allocated 3908.092 megabytes *** Exitification transformation [HsInstances]: Result size of Exitification transformation = {terms: 88,115, types: 411,518, coercions: 243,081, joins: 292/3,052} !!! Exitification transformation [HsInstances]: finished in 43.61 milliseconds, allocated 33.863 megabytes *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [HsInstances]: Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) = {terms: 90,071, types: 413,216, coercions: 243,081, joins: 0/2,760} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [HsInstances]: finished in 801.06 milliseconds, allocated 1044.681 megabytes *** Common sub-expression [HsInstances]: Result size of Common sub-expression = {terms: 83,216, types: 403,886, coercions: 242,872, joins: 0/2,760} !!! Common sub-expression [HsInstances]: finished in 415.19 milliseconds, allocated 768.373 megabytes *** Float inwards [HsInstances]: Result size of Float inwards = {terms: 83,216, types: 403,886, coercions: 242,872, joins: 0/2,760} !!! Float inwards [HsInstances]: finished in 289.80 milliseconds, allocated 470.782 megabytes *** Liberate case [HsInstances]: Result size of Liberate case = {terms: 83,216, types: 403,886, coercions: 242,872, joins: 0/2,760} !!! Liberate case [HsInstances]: finished in 73.12 milliseconds, allocated 103.518 megabytes *** Simplifier [HsInstances]: Result size of Simplifier iteration=1 = {terms: 79,540, types: 395,132, coercions: 242,872, joins: 0/2,760} Result size of Simplifier = {terms: 79,540, types: 395,132, coercions: 242,872, joins: 0/2,760} !!! Simplifier [HsInstances]: finished in 1477.16 milliseconds, allocated 1796.773 megabytes *** SpecConstr [HsInstances]: Result size of SpecConstr = {terms: 79,540, types: 395,132, coercions: 242,872, joins: 0/2,760} !!! SpecConstr [HsInstances]: finished in 433.32 milliseconds, allocated 658.733 megabytes *** Simplifier [HsInstances]: Result size of Simplifier = {terms: 79,540, types: 395,132, coercions: 242,872, joins: 0/2,760} !!! Simplifier [HsInstances]: finished in 731.25 milliseconds, allocated 872.946 megabytes *** Demand analysis [HsInstances]: Result size of Demand analysis = {terms: 79,540, types: 395,132, coercions: 242,872, joins: 0/2,760} !!! Demand analysis [HsInstances]: finished in 2900.86 milliseconds, allocated 3463.096 megabytes *** CoreTidy [HsInstances]: Result size of Tidy Core = {terms: 78,322, types: 391,734, coercions: 242,749, joins: 0/2,760} !!! CoreTidy [HsInstances]: finished in 268.39 milliseconds, allocated 337.202 megabytes writeBinIface: 3171 Names writeBinIface: 3487 dict entries writeBinIface: 3171 Names writeBinIface: 3487 dict entries Created temporary directory: /tmp/ghc7250_0 *** CorePrep [HsInstances]: Result size of CorePrep = {terms: 100,011, types: 474,602, coercions: 242,749, joins: 0/10,157} !!! CorePrep [HsInstances]: finished in 237.39 milliseconds, allocated 349.483 megabytes *** Stg2Stg: *** CodeGen [HsInstances]: !!! CodeGen [HsInstances]: finished in 5228.65 milliseconds, allocated 8228.633 megabytes *** Assembler: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -Icompiler/hsSyn -Icompiler/stage3/build -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -Icompiler/stage3/build -Icompiler/stage3/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -no-pie -x assembler -c /tmp/ghc7250_0/ghc_1.s -o compiler/stage3/build/HsInstances.o *** CorePrep [HsInstances]: Result size of CorePrep = {terms: 100,011, types: 474,602, coercions: 242,749, joins: 0/10,157} !!! CorePrep [HsInstances]: finished in 283.31 milliseconds, allocated 348.963 megabytes *** Stg2Stg: *** CodeGen [HsInstances]: !!! CodeGen [HsInstances]: finished in 8840.65 milliseconds, allocated 8731.219 megabytes *** Assembler: }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 19:49:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 19:49:59 -0000 Subject: [GHC] #14468: Why does alanz's branch blow up GHC's heap? In-Reply-To: <046.be390aa8ac1f4abd294d2b3b0f58b57c@haskell.org> References: <046.be390aa8ac1f4abd294d2b3b0f58b57c@haskell.org> Message-ID: <061.8874a614332cc4350b99d9c62fd15e7b@haskell.org> #14468: Why does alanz's branch blow up GHC's heap? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.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 bgamari): The dominant entries in the profile are, {{{ tcRnModule' HscMain compiler/main/HscMain.hs:(460,1)-(499,72) 1549 1 0.0 0.0 40.5 44.2 tcRnSrcDecls TcRnDriver compiler/typecheck/TcRnDriver.hs:259:25-65 1562 1 0.0 0.0 40.1 43.8 simplifyTop TcRnDriver compiler/typecheck/TcRnDriver.hs:413:25-39 1582 1 1.3 1.2 16.8 18.1 solveSimples TcInteract compiler/typecheck/TcInteract.hs:(240,5)-(241,21) 1583 3215 0.0 0.0 15.5 16.9 solve_loop TcInteract compiler/typecheck/TcInteract.hs:(245,9)-(249,44) 1584 0 7.8 9.1 15.4 16.9 zonkTopDecls TcRnDriver compiler/typecheck/TcRnDriver.hs:(446,16)-(447,43) 1588 1 0.6 0.8 17.1 18.7 zonkEvBinds TcHsSyn compiler/typecheck/TcHsSyn.hs:(1497,5)-(1500,35) 1589 5630 12.0 13.1 16.5 17.9 }}} Clearly more cost centres are needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:05:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:05:28 -0000 Subject: [GHC] #14206: Add bit deposit and bit extraction primops In-Reply-To: <047.2543734720307265ea1bddd575e5fddb@haskell.org> References: <047.2543734720307265ea1bddd575e5fddb@haskell.org> Message-ID: <062.c205631d83e2f17ab96dc0e69f7eb20f@haskell.org> #14206: Add bit deposit and bit extraction primops -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Ben Gamari ): In [changeset:"f5dc8ccc29429d0a1d011f62b6b430f6ae50290c/ghc" f5dc8ccc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f5dc8ccc29429d0a1d011f62b6b430f6ae50290c" Add new mbmi and mbmi2 compiler flags This adds support for the bit deposit and extraction operations provided by the BMI and BMI2 instruction set extensions on modern amd64 machines. Test Plan: Validate Reviewers: austin, simonmar, bgamari, hvr, goldfire, erikd Reviewed By: bgamari Subscribers: goldfire, erikd, trommler, newhoggy, rwbarton, thomie GHC Trac Issues: #14206 Differential Revision: https://phabricator.haskell.org/D4063 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:05:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:05:28 -0000 Subject: [GHC] #14353: PowerPC: HEAD validate fails due to warnings in libffi In-Reply-To: <047.961ea899fd8ff2b7dcf4d0bb882f6d5d@haskell.org> References: <047.961ea899fd8ff2b7dcf4d0bb882f6d5d@haskell.org> Message-ID: <062.2faa66b83734af51f3b849c33b41a9b6@haskell.org> #14353: PowerPC: HEAD validate fails due to warnings in libffi ----------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4181 Wiki Page: | ----------------------------------------+---------------------------------- Comment (by Ben Gamari ): In [changeset:"8b1020ed21ec8af1accdd900f0d48c3c92b6ed83/ghc" 8b1020ed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8b1020ed21ec8af1accdd900f0d48c3c92b6ed83" RTS: Disable warnings in ffi.h The update of GHC's in-tree libffi causes warnings about undefined macros and hence validate fails. Also mark broken tests that have a ticket. Fixes #14353 Test Plan: ./validate (on AIX and powerpc if possible) Reviewers: bgamari, hvr, erikd, simonmar Reviewed By: bgamari Subscribers: snowleopard, rwbarton, thomie GHC Trac Issues: #14353, #11259, #14455, #11261 Differential Revision: https://phabricator.haskell.org/D4181 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:05:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:05:28 -0000 Subject: [GHC] #11259: Use system runtime linker in GHCi on PowerPC 64 bit In-Reply-To: <047.f1dbe111d1a2b1b825a51a6a842cbde6@haskell.org> References: <047.f1dbe111d1a2b1b825a51a6a842cbde6@haskell.org> Message-ID: <062.0fa75f58938d7a42b2085619a3b1e191@haskell.org> #11259: Use system runtime linker in GHCi on PowerPC 64 bit -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: GHCi crash | Test Case: ghcilink004, | prog001, and 11 more Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8b1020ed21ec8af1accdd900f0d48c3c92b6ed83/ghc" 8b1020ed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8b1020ed21ec8af1accdd900f0d48c3c92b6ed83" RTS: Disable warnings in ffi.h The update of GHC's in-tree libffi causes warnings about undefined macros and hence validate fails. Also mark broken tests that have a ticket. Fixes #14353 Test Plan: ./validate (on AIX and powerpc if possible) Reviewers: bgamari, hvr, erikd, simonmar Reviewed By: bgamari Subscribers: snowleopard, rwbarton, thomie GHC Trac Issues: #14353, #11259, #14455, #11261 Differential Revision: https://phabricator.haskell.org/D4181 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:05:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:05:28 -0000 Subject: [GHC] #11261: Implement DWARF debugging on powerpc64 In-Reply-To: <047.fcb308b656617448e39264eeafa29658@haskell.org> References: <047.fcb308b656617448e39264eeafa29658@haskell.org> Message-ID: <062.2bf9b98cab70aca18d708f74c2e3d744@haskell.org> #11261: Implement DWARF debugging on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: debug, at runtime | T10667, | simplCore/should_compile/T13658 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8b1020ed21ec8af1accdd900f0d48c3c92b6ed83/ghc" 8b1020ed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8b1020ed21ec8af1accdd900f0d48c3c92b6ed83" RTS: Disable warnings in ffi.h The update of GHC's in-tree libffi causes warnings about undefined macros and hence validate fails. Also mark broken tests that have a ticket. Fixes #14353 Test Plan: ./validate (on AIX and powerpc if possible) Reviewers: bgamari, hvr, erikd, simonmar Reviewed By: bgamari Subscribers: snowleopard, rwbarton, thomie GHC Trac Issues: #14353, #11259, #14455, #11261 Differential Revision: https://phabricator.haskell.org/D4181 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:05:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:05:28 -0000 Subject: [GHC] #14455: PPC64: Wrong output in print022 In-Reply-To: <047.0bdf060fac19303d5cc090cf0af4b401@haskell.org> References: <047.0bdf060fac19303d5cc090cf0af4b401@haskell.org> Message-ID: <062.e97a9c0a75fd3777af1d7e84f1aaa6b9@haskell.org> #14455: PPC64: Wrong output in print022 -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.3 Resolution: | Keywords: big endian Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | ghci.debugger/scripts/print022 | ghci.debugger/scripts/T13825-debugger Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8b1020ed21ec8af1accdd900f0d48c3c92b6ed83/ghc" 8b1020ed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8b1020ed21ec8af1accdd900f0d48c3c92b6ed83" RTS: Disable warnings in ffi.h The update of GHC's in-tree libffi causes warnings about undefined macros and hence validate fails. Also mark broken tests that have a ticket. Fixes #14353 Test Plan: ./validate (on AIX and powerpc if possible) Reviewers: bgamari, hvr, erikd, simonmar Reviewed By: bgamari Subscribers: snowleopard, rwbarton, thomie GHC Trac Issues: #14353, #11259, #14455, #11261 Differential Revision: https://phabricator.haskell.org/D4181 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:05:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:05:28 -0000 Subject: [GHC] #14445: GC timing stats (e.g. mutator_elapsed_ns) decrease over time In-Reply-To: <047.81a01718a79512286f0bf0342273b9da@haskell.org> References: <047.81a01718a79512286f0bf0342273b9da@haskell.org> Message-ID: <062.dbf65173452d713087a783ed348d15e8@haskell.org> #14445: GC timing stats (e.g. mutator_elapsed_ns) decrease over time -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #14257, #14006, | Differential Rev(s): #11645 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d9f0c24dd01b2f2a9a5ccc2fc45e93064d4ba0c1/ghc" d9f0c24d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d9f0c24dd01b2f2a9a5ccc2fc45e93064d4ba0c1" rts: Fix gc timing We were accumulating the gc times of the previous gc. `stats.gc.{cpu,elappsed}_ns` were being accumulated into `stats.gc_{cpu,elapsed}_ns` before they were set. There is also a change in that heap profiling will no longer cause gc events to be emitted. Reviewers: bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14257, #14445 Differential Revision: https://phabricator.haskell.org/D4184 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:05:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:05:28 -0000 Subject: [GHC] #14464: Adjust AltCon Ord instance to match linter requirements. In-Reply-To: <047.6247340d9480dc11fbdad08efa8e8bc5@haskell.org> References: <047.6247340d9480dc11fbdad08efa8e8bc5@haskell.org> Message-ID: <062.bc3dfb603b103a98ded20922722dfd70@haskell.org> #14464: Adjust AltCon Ord instance to match linter requirements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.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): Phab:D4198 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e14945ce046a000f1542818cd5cb6007cf2e2422/ghc" e14945c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e14945ce046a000f1542818cd5cb6007cf2e2422" Adjust AltCon Ord instance to match Core linter requirements. When sorting by the Ord instance put DEFAULT before other constructors. This is in line with what the core linter requests allowing the use of the instance for putting alternatives in the correct order. This implements #14464. Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #14464 Differential Revision: https://phabricator.haskell.org/D4198 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:05:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:05:28 -0000 Subject: [GHC] #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) In-Reply-To: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> References: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> Message-ID: <064.590dfb4ed9826578a305333e9afb6265@haskell.org> #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) -------------------------------------+------------------------------------- Reporter: carlostome | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: profiler Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14006, #11645 | Differential Rev(s): Phab:D4184 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d9f0c24dd01b2f2a9a5ccc2fc45e93064d4ba0c1/ghc" d9f0c24d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d9f0c24dd01b2f2a9a5ccc2fc45e93064d4ba0c1" rts: Fix gc timing We were accumulating the gc times of the previous gc. `stats.gc.{cpu,elappsed}_ns` were being accumulated into `stats.gc_{cpu,elapsed}_ns` before they were set. There is also a change in that heap profiling will no longer cause gc events to be emitted. Reviewers: bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14257, #14445 Differential Revision: https://phabricator.haskell.org/D4184 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:05:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:05:28 -0000 Subject: [GHC] #14454: Unregisterised build is broken In-Reply-To: <046.16eab3f0c63c2818b23a6ad81d240445@haskell.org> References: <046.16eab3f0c63c2818b23a6ad81d240445@haskell.org> Message-ID: <061.09b8dfd8cd849be0652dbb13a81542b7@haskell.org> #14454: Unregisterised build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.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 Ben Gamari ): In [changeset:"ea26162226fa04d3d21f6ce3fdf36e83355274c9/ghc" ea26162/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ea26162226fa04d3d21f6ce3fdf36e83355274c9" CLabel: Clean up unused label types Test Plan: Validate Reviewers: trommler, simonmar Reviewed By: trommler Subscribers: rwbarton, thomie GHC Trac Issues: #14454 Differential Revision: https://phabricator.haskell.org/D4182 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:06:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:06:39 -0000 Subject: [GHC] #14206: Add bit deposit and bit extraction primops In-Reply-To: <047.2543734720307265ea1bddd575e5fddb@haskell.org> References: <047.2543734720307265ea1bddd575e5fddb@haskell.org> Message-ID: <062.17b6bd57317b9d3bf869dc6bd73f3291@haskell.org> #14206: Add bit deposit and bit extraction primops -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 Comment: Thanks newhoggy! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:07:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:07:15 -0000 Subject: [GHC] #14353: PowerPC: HEAD validate fails due to warnings in libffi In-Reply-To: <047.961ea899fd8ff2b7dcf4d0bb882f6d5d@haskell.org> References: <047.961ea899fd8ff2b7dcf4d0bb882f6d5d@haskell.org> Message-ID: <062.8a1aa4af29470a77219a03ad455f7a64@haskell.org> #14353: PowerPC: HEAD validate fails due to warnings in libffi ----------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4181 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 Comment: I've updated hadrian as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:09:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:09:47 -0000 Subject: [GHC] #14464: Adjust AltCon Ord instance to match linter requirements. In-Reply-To: <047.6247340d9480dc11fbdad08efa8e8bc5@haskell.org> References: <047.6247340d9480dc11fbdad08efa8e8bc5@haskell.org> Message-ID: <062.194173b1372c20051a8a6213ffaf327f@haskell.org> #14464: Adjust AltCon Ord instance to match linter requirements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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:D4198 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:10:46 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:10:46 -0000 Subject: [GHC] #14450: GHCi spins forever In-Reply-To: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> References: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> Message-ID: <066.d1cc2e77108ec69a2f7a097810b159c1@haskell.org> #14450: GHCi spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: TypeInType, | PolyKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | polykinds/T14450 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Is this an instance of the same bug? Loops on 8.3.20170920 and 8.2 {{{#!hs {-# Language KindSignatures, TypeOperators, PolyKinds, DataKinds, TypeInType, TypeFamilies, AllowAmbiguousTypes #-} import Data.Kind type a-->b = (a, b) -> Type type Cat k = k -> k -> Type class F (f::k-->k') where type D f :: Cat k type C f :: Cat k' f :: D f a a' -> C d (App f a) (App f a') data DupSym0 :: a --> (a, a) type family App (f::a-->b) (x::a) :: b where App DupSym0 a = '(a, a) instance F DupSym0 where type D DupSym0 = (->) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:17:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:17:58 -0000 Subject: [GHC] #14450: GHCi spins forever In-Reply-To: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> References: <051.0d97b44ffb6070ac3b03452f414b544b@haskell.org> Message-ID: <066.c8d49dee7d77977a3e6924218337759b@haskell.org> #14450: GHCi spins forever -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: TypeInType, | PolyKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | polykinds/T14450 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): That program errors for me on the latest GHC HEAD: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.3.20171111: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:21:20: error: • Expected kind ‘k -> k -> *’, but ‘(->)’ has kind ‘* -> * -> *’ • In the type ‘(->)’ In the type instance declaration for ‘D’ In the instance declaration for ‘F DupSym0’ | 21 | type D DupSym0 = (->) | ^^^^ }}} So I'd wager that it's the same issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:24:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:24:44 -0000 Subject: [GHC] #14469: Rebuilding profiled stage2 after building stage3 is broken Message-ID: <046.384ad4c4e2b35a6f95f50027c745b4cd@haskell.org> #14469: Rebuilding profiled stage2 after building stage3 is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.2.1 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 appears to break, {{{ $ cat <mk/build.mk BuildFlavour = prof ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif EOF $ make stage=2 $ make stage=3 $ touch compiler/stage2/build/Simplify.* $ make stage=2 ... ghc/GHCi/UI/Info.hs:43:1: error: Could not find module ‘TcHsSyn’ Perhaps you haven't installed the profiling libraries for package ‘ghc-8.3’? Locations searched: ghc/./TcHsSyn.p_hi ghc/./TcHsSyn.p_hi-boot ghc/stage2/build/TcHsSyn.p_hi ghc/stage2/build/TcHsSyn.p_hi-boot ghc/stage2/build/ghc/autogen/TcHsSyn.p_hi ghc/stage2/build/ghc/autogen/TcHsSyn.p_hi-boot /mnt/work/ghc/ghc/compiler/stage3/build/TcHsSyn.p_hi | 43 | import TcHsSyn | ^^^^^^^^^^^^^^^^^^^^^^^^ }}} The problem appears to be that the build system registers the stage3 `ghc`, which we didn't build in the profiled way, overwriting the stage2 registration. Hopefully Hadrian will do better here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:27:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:27:10 -0000 Subject: [GHC] #14467: Support HasCallStack for calls to panic In-Reply-To: <047.e62d0844ad019ed17459f279733f58a5@haskell.org> References: <047.e62d0844ad019ed17459f279733f58a5@haskell.org> Message-ID: <062.8f56f2944ddd25286ef62e83e6d7bda1@haskell.org> #14467: Support HasCallStack for calls to panic -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: GHC API | Version: 8.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 bgamari): For what it's worth, `pprPanic` already takes a callstack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:39:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:39:22 -0000 Subject: [GHC] #14460: Can't decompose ghc.exe path In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.b49cd9bf181b276b1479f798baa608ce@haskell.org> #14460: Can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | 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 Phyx-): No, your `lib` folder, not the `bin` folder. The path I pasted is different from the one you reported. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:44:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:44:23 -0000 Subject: [GHC] #11295: Figure out what LLVM passes are fruitful In-Reply-To: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> References: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> Message-ID: <061.0a29d401f3c08d952d12734014806dd3@haskell.org> #11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: kavon Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.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 bgamari): > What do you think? Sounds good to me. Looking forward to it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:44:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:44:50 -0000 Subject: [GHC] #14460: Can't decompose ghc.exe path In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.0b13241fb8e5a206b60592776b17aee9@haskell.org> #14460: Can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | 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 astert): Oh, sorry. It definitely should exist, I'm 90% sure it does, but I'll double check later when I have access to the computer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 20:54:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 20:54:37 -0000 Subject: [GHC] #14335: Annotations aren't supported with -fexternal-interpreter In-Reply-To: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> References: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> Message-ID: <061.f0a4c4dbaa7f6b076d9adfdad9946f6e@haskell.org> #14335: Annotations aren't supported with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It looks like running `plugins01` with `-fexternal-interpreter` should do the trick. I'll add one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 21:14:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 21:14:02 -0000 Subject: [GHC] #14335: Annotations aren't supported with -fexternal-interpreter In-Reply-To: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> References: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> Message-ID: <061.ce92abe8cb26ecfc74f7e94c0fd0143a@haskell.org> #14335: Annotations aren't supported with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14335 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => T14335 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 21:52:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 21:52:44 -0000 Subject: [GHC] #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) In-Reply-To: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> References: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> Message-ID: <064.b75c8ccd0a782d6237abadad839876ca@haskell.org> #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) -------------------------------------+------------------------------------- Reporter: carlostome | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: fixed | Keywords: profiler Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14006, #11645 | Differential Rev(s): Phab:D4184 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 21:52:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 21:52:58 -0000 Subject: [GHC] #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) In-Reply-To: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> References: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> Message-ID: <064.cc6dc5621366e212aed2d8cb2a5f8aab@haskell.org> #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) -------------------------------------+------------------------------------- Reporter: carlostome | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: fixed | Keywords: profiler Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14257 Blocked By: | Blocking: Related Tickets: #14006, #11645 | Differential Rev(s): Phab:D4184 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => T14257 Comment: Test coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 21:53:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 21:53:19 -0000 Subject: [GHC] #14445: GC timing stats (e.g. mutator_elapsed_ns) decrease over time In-Reply-To: <047.81a01718a79512286f0bf0342273b9da@haskell.org> References: <047.81a01718a79512286f0bf0342273b9da@haskell.org> Message-ID: <062.dbf4d5d2ce52eb61cade8c579ade667a@haskell.org> #14445: GC timing stats (e.g. mutator_elapsed_ns) decrease over time -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #14257, #14006, | Differential Rev(s): #11645 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 21:59:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 21:59:43 -0000 Subject: [GHC] #452: +RTS -xc and SIGINT handler gives seg fault In-Reply-To: <045.d37eb0ddf1ca9fd8159bb0092b6f82b5@haskell.org> References: <045.d37eb0ddf1ca9fd8159bb0092b6f82b5@haskell.org> Message-ID: <060.b9ecfb2cfe8395465bc0a300a071c2e7@haskell.org> #452: +RTS -xc and SIGINT handler gives seg fault --------------------------------+-------------------- Reporter: fergus | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Profiling | Version: None Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Changes (by Andrey Mokhov ): * failure: => None/Unknown Comment: In [changeset:"c1fcd9b3f60e8420dd228cd4e3efeb9cfa793aa5/ghc" c1fcd9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c1fcd9b3f60e8420dd228cd4e3efeb9cfa793aa5" Squashed 'hadrian/' changes from 5ebb69a..fa3771f fa3771f hadrian: Disable -Wno-undef in files which include ffi.h (#459) f15e851 Do not run configure by default (#458) 5baa8db Fix AppVeyor cache failure (#456) 94dbe9d Fix ghc-cabal build (#455) a679764 Fix CI scripts (#454) 06ec241 Widen bounds on Cabal (#452) git-subtree-dir: hadrian git-subtree-split: fa3771fe6baf5008a8506fec48220f8347ac59af }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 21:59:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 21:59:43 -0000 Subject: [GHC] #458: Warning -fwarn-unused-imports does not go away In-Reply-To: <045.17446174a3ccb2a496a4e8970aafc983@haskell.org> References: <045.17446174a3ccb2a496a4e8970aafc983@haskell.org> Message-ID: <060.86f1dbb3c6008f68b70cdc953235beee@haskell.org> #458: Warning -fwarn-unused-imports does not go away --------------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: None Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Changes (by Andrey Mokhov ): * failure: => None/Unknown Comment: In [changeset:"c1fcd9b3f60e8420dd228cd4e3efeb9cfa793aa5/ghc" c1fcd9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c1fcd9b3f60e8420dd228cd4e3efeb9cfa793aa5" Squashed 'hadrian/' changes from 5ebb69a..fa3771f fa3771f hadrian: Disable -Wno-undef in files which include ffi.h (#459) f15e851 Do not run configure by default (#458) 5baa8db Fix AppVeyor cache failure (#456) 94dbe9d Fix ghc-cabal build (#455) a679764 Fix CI scripts (#454) 06ec241 Widen bounds on Cabal (#452) git-subtree-dir: hadrian git-subtree-split: fa3771fe6baf5008a8506fec48220f8347ac59af }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 21:59:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 21:59:43 -0000 Subject: [GHC] #456: panic:Unify.unifyTauTyLists In-Reply-To: <047.b1d88ac28c3dac5066713792b4f07d7a@haskell.org> References: <047.b1d88ac28c3dac5066713792b4f07d7a@haskell.org> Message-ID: <062.7eab821cf241d37f27dba5ca0ce2bf32@haskell.org> #456: panic:Unify.unifyTauTyLists -------------------------------------------+-------------------- Reporter: volkersf | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.4 Resolution: Duplicate | Keywords: Type of failure: None/Unknown | -------------------------------------------+-------------------- Changes (by Andrey Mokhov ): * failure: => None/Unknown Comment: In [changeset:"c1fcd9b3f60e8420dd228cd4e3efeb9cfa793aa5/ghc" c1fcd9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c1fcd9b3f60e8420dd228cd4e3efeb9cfa793aa5" Squashed 'hadrian/' changes from 5ebb69a..fa3771f fa3771f hadrian: Disable -Wno-undef in files which include ffi.h (#459) f15e851 Do not run configure by default (#458) 5baa8db Fix AppVeyor cache failure (#456) 94dbe9d Fix ghc-cabal build (#455) a679764 Fix CI scripts (#454) 06ec241 Widen bounds on Cabal (#452) git-subtree-dir: hadrian git-subtree-split: fa3771fe6baf5008a8506fec48220f8347ac59af }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 21:59:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 21:59:43 -0000 Subject: [GHC] #455: mkProtoBCO: stack use won't fit in 16 bits 79141 In-Reply-To: <047.d6ec5bdb5ccff4ce3c3454408860cc3e@haskell.org> References: <047.d6ec5bdb5ccff4ce3c3454408860cc3e@haskell.org> Message-ID: <062.42aec47026802279e81a0b15511fd23a@haskell.org> #455: mkProtoBCO: stack use won't fit in 16 bits 79141 -------------------------------------+--------------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.6.1 Component: GHCi | Version: 6.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: ghci003 -------------------------------------+--------------------------------- Changes (by Andrey Mokhov ): * failure: => None/Unknown Comment: In [changeset:"c1fcd9b3f60e8420dd228cd4e3efeb9cfa793aa5/ghc" c1fcd9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c1fcd9b3f60e8420dd228cd4e3efeb9cfa793aa5" Squashed 'hadrian/' changes from 5ebb69a..fa3771f fa3771f hadrian: Disable -Wno-undef in files which include ffi.h (#459) f15e851 Do not run configure by default (#458) 5baa8db Fix AppVeyor cache failure (#456) 94dbe9d Fix ghc-cabal build (#455) a679764 Fix CI scripts (#454) 06ec241 Widen bounds on Cabal (#452) git-subtree-dir: hadrian git-subtree-split: fa3771fe6baf5008a8506fec48220f8347ac59af }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 21:59:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 21:59:43 -0000 Subject: [GHC] #454: hPutBuf doesn't respect LineBuffering In-Reply-To: <047.0ae23113bdabf18ce84f68bc410637a0@haskell.org> References: <047.0ae23113bdabf18ce84f68bc410637a0@haskell.org> Message-ID: <062.2a75721a013424b89585533687c31898@haskell.org> #454: hPutBuf doesn't respect LineBuffering -------------------------------------+--------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 6.12.1 Component: libraries/base | Version: 6.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: -------------------------------------+--------------------------------- Changes (by Andrey Mokhov ): * failure: => None/Unknown Comment: In [changeset:"c1fcd9b3f60e8420dd228cd4e3efeb9cfa793aa5/ghc" c1fcd9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c1fcd9b3f60e8420dd228cd4e3efeb9cfa793aa5" Squashed 'hadrian/' changes from 5ebb69a..fa3771f fa3771f hadrian: Disable -Wno-undef in files which include ffi.h (#459) f15e851 Do not run configure by default (#458) 5baa8db Fix AppVeyor cache failure (#456) 94dbe9d Fix ghc-cabal build (#455) a679764 Fix CI scripts (#454) 06ec241 Widen bounds on Cabal (#452) git-subtree-dir: hadrian git-subtree-split: fa3771fe6baf5008a8506fec48220f8347ac59af }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 21:59:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 21:59:43 -0000 Subject: [GHC] #459: Bad parse error message In-Reply-To: <045.9adecc17314923c33323a1bd4204dfc1@haskell.org> References: <045.9adecc17314923c33323a1bd4204dfc1@haskell.org> Message-ID: <060.0f66f625fa220c7bbb74e8e0c4361e3c@haskell.org> #459: Bad parse error message --------------------------------------+--------------------------------- Reporter: nobody | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler (Parser) | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | --------------------------------------+--------------------------------- Comment (by Andrey Mokhov ): In [changeset:"c1fcd9b3f60e8420dd228cd4e3efeb9cfa793aa5/ghc" c1fcd9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c1fcd9b3f60e8420dd228cd4e3efeb9cfa793aa5" Squashed 'hadrian/' changes from 5ebb69a..fa3771f fa3771f hadrian: Disable -Wno-undef in files which include ffi.h (#459) f15e851 Do not run configure by default (#458) 5baa8db Fix AppVeyor cache failure (#456) 94dbe9d Fix ghc-cabal build (#455) a679764 Fix CI scripts (#454) 06ec241 Widen bounds on Cabal (#452) git-subtree-dir: hadrian git-subtree-split: fa3771fe6baf5008a8506fec48220f8347ac59af }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 23:10:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 23:10:53 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.05acc67ff698289074067537e47434c2@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by chris_r_timmons): * Attachment "T12891.py" added. Python 3 script that attempts to determine which symbols in includes/Rts.h do not appear in rts/RtsSymbols.c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 15 23:12:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Nov 2017 23:12:55 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.a83c7a8e07a36f1cca15b9e7eb86e768@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chris_r_timmons): I've attached a Python 3 script that attempts to show what symbols in includes/Rts.h are missing from rts/RtsSymbols.c. A comment at the top of the script contains an overview of the algorithm and usage details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 00:23:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 00:23:08 -0000 Subject: [GHC] #14470: CircleCI: Detect number of processors Message-ID: <046.012116c89dd22a1fbfc06a0f6d331f82@haskell.org> #14470: CircleCI: Detect number of processors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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 we hard-code the thread count to 8, which is what the machines which jobs from the `ghc/ghc` repository run on. However, such machines are not available to owners of `ghc` forks (unless they specifically request a resource limit bump from CircleCI). We should automatically detect the CPU count to ensure that CI on smaller instances will not fail due to oversubscription. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 00:29:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 00:29:51 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.1a351c18d6bae2f69f56e45421c4a45c@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13497, 13525 | Blocking: Related Tickets: #12912, #13525 | Differential Rev(s): Phab:D42 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Hmm, in [https://books.google.ch/books?id=r5tCAwAAQBAJ&pg=PT636&lpg=PT636&dq=CancelSynchronousIo++ERROR_NOT_FOUND&source=bl&ots=PS_yalzoMX&sig =hM- 5HzjZGwu66hal48xjV50kYsU&hl=en&sa=X&ved=0ahUKEwj0uvaI1sHXAhXDHxoKHdsDB_YQ6AEIRDAF#v=onepage&q=CancelSynchronousIo%20%20ERROR_NOT_FOUND&f=false this book] **Windows via C/C++** it says > Note that the thread calling `CancelSynchronousIo` doesn't really know where the thread that called the synchronous operation is. The thread could have been pre-empted and it has yet to actually communicate with the device; it could be suspended, waiting for the device to respond; or the device could have just responded, and the thread is in the process of returning from its call. If `CancelSynchronousIo` is called when the specified thread is not actually suspended waiting for the device to respond, `CancelSynchronousIo` returns `FALSE` and `GetLastError` returns error not found. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 01:34:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 01:34:44 -0000 Subject: [GHC] #14471: Certain do blocks cause TH to barf when ApplicativeDo is enabled Message-ID: <050.4f7b341f8e72d76f8691291adb62b498@haskell.org> #14471: Certain do blocks cause TH to barf when ApplicativeDo is enabled -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.2.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program fails with an error: {{{#!hs {-# LANGUAGE ApplicativeDo #-} {-# LANGUAGE TemplateHaskell #-} main = $([|do return () return () return ()|]) }}} {{{ Exotic.hs:4:12: error: Exotic statement not (yet) handled by Template Haskell [return (); return (), return ()] }}} It only happens when `ApplicativeDo` is enabled. Furthermore, while this example is extremely minimal, this issue isn’t restricted to `ApplicativeDo`’s special handling of `return`. The following example produces the same error: {{{#!hs {-# LANGUAGE ApplicativeDo #-} {-# LANGUAGE TemplateHaskell #-} main = $([|do getLine getLine getLine|]) }}} {{{ Exotic.hs:4:12: error: Exotic statement not (yet) handled by Template Haskell [getLine; getLine, getLine] }}} This ''doesn’t'' happen with fewer than three statements in the `do` block, but it ''does'' happen with more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 02:20:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 02:20:55 -0000 Subject: [GHC] #14460: Can't decompose ghc.exe path In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.9612218fc7bacc4aedf783a1d1ffd42a@haskell.org> #14460: Can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | 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 astert): Can confirm that the lib directory does exist. I'll try uninstalling and reinstalling it and see if the problem persists. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 02:51:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 02:51:33 -0000 Subject: [GHC] #14460: Can't decompose ghc.exe path In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.d0ead0b15e346e4bf0847b0eb9f1f167@haskell.org> #14460: Can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | 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 astert): Uninstalling and reinstalling didn't help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 09:08:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 09:08:02 -0000 Subject: [GHC] #14472: error __STDC_VERSION__ does not advertise C99 or later Message-ID: <049.e4bf88da72057e68816cb5a52de32755@haskell.org> #14472: error __STDC_VERSION__ does not advertise C99 or later -------------------------------------+------------------------------------- Reporter: kaldiroglu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, I am using Mac OS highSierra 10.13.1 and downloaded and installed Haskell Platform 8.2.1 Full 64bit-signed.pkg. Then as a first program I created a file called Selam.hs that includes followng one line: "main = putStrLn "Hello, world!"" When I compiled the code using ghc -o Selam Selam.hs at the linking phase I am having "error __STDC_VERSION__ does not advertise C99 or later" error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 09:08:36 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 09:08:36 -0000 Subject: [GHC] #14472: error __STDC_VERSION__ does not advertise C99 or later In-Reply-To: <049.e4bf88da72057e68816cb5a52de32755@haskell.org> References: <049.e4bf88da72057e68816cb5a52de32755@haskell.org> Message-ID: <064.9d90fe19262be577a119d525262c744e@haskell.org> #14472: error __STDC_VERSION__ does not advertise C99 or later -------------------------------------+------------------------------------- Reporter: kaldiroglu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kaldiroglu): * Attachment "Screen Shot 2017-11-16 at 12.01.51.png" added. Screen shot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 12:58:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 12:58:38 -0000 Subject: [GHC] #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) Message-ID: <047.9478e62bd80e36e2a95f7745037003bc@haskell.org> #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) -------------------------------------+------------------------------------- Reporter: takenobu | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13126 #9224 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Implement Underscores in Numeric Literals Proposal. GHC supports various numeric literals such as decimal, octal, hexadecimal, binary, and floating point numbers. However, large numeric literals are hard to read. This proposal improves the readability, quality, expressiveness of numeric literals. This proposal allows underscores to numeric literals when the `NumericUnderscores` language extension is enabled. Underscores (`_`) in numeric literals are simply ignored. The specification of the feature is available here:\\ ​https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0009 -numeric-underscores.rst For a discussion:\\ https://github.com/ghc-proposals/ghc-proposals/pull/76 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 13:31:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 13:31:49 -0000 Subject: [GHC] #14443: Add a plugin phase that allows users to modify HsSyn before the desugarer In-Reply-To: <047.db01a8d384aae8d61e8f07147cee7c20@haskell.org> References: <047.db01a8d384aae8d61e8f07147cee7c20@haskell.org> Message-ID: <062.3b6bb2230aa4b4c73ce1f871606a0d97@haskell.org> #14443: Add a plugin phase that allows users to modify HsSyn before the desugarer -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Shayan-Najd): That's similar to what [https://ghc.haskell.org/trac/ghc/wiki/NativeMetaprogramming| native metaprogramming] would eventually allow you to do. Meanwhile, can't you already do this with Template Haskell (with a bit of more syntactic noise)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 14:30:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 14:30:41 -0000 Subject: [GHC] #14443: Add a plugin phase that allows users to modify HsSyn before the desugarer In-Reply-To: <047.db01a8d384aae8d61e8f07147cee7c20@haskell.org> References: <047.db01a8d384aae8d61e8f07147cee7c20@haskell.org> Message-ID: <062.4cc3eafa8c5896e171439e69c3552b03@haskell.org> #14443: Add a plugin phase that allows users to modify HsSyn before the desugarer -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 ocharles): > Meanwhile, can't you already do this with Template Haskell (with a bit of more syntactic noise)? I don't believe I can, as I need access to the type checker to see which things I can `Show`. Thanks for the link to Native Metaprogramming, I'll have a read. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 15:16:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 15:16:17 -0000 Subject: [GHC] #14396: Hs-boot woes during family instance consistency checks In-Reply-To: <046.2ccc4fa31be03dddd3503a257243a5e2@haskell.org> References: <046.2ccc4fa31be03dddd3503a257243a5e2@haskell.org> Message-ID: <061.3344529b881e801ea79ef62d81b8272d@haskell.org> #14396: Hs-boot woes during family instance consistency checks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4154 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I attempted to trigger the error case simonpj described, with the new patchset, by writing this T.hs instead: {{{ -- T.hs module T where import T1 import T2 data SyntaxExpr = S f :: XListPat Int -> () f S = () }}} But I didn't succeed. The idea is that type family consistency checking might have caused the family instance to force the thunk for SyntaxExpr early, so that the instance reduction will point to the wrong thing, but this does not seem to have happened. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 15:30:34 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 15:30:34 -0000 Subject: [GHC] #14474: reify RHS of "value" variable Message-ID: <048.71df88e13081a2901e79c4bd24859fe9@haskell.org> #14474: reify RHS of "value" variable -------------------------------------+------------------------------------- Reporter: dailectic | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.2.1 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: -------------------------------------+------------------------------------- According to the [https://hackage.haskell.org/package/template- haskell-2.12.0.0/docs/Language-Haskell-TH-Syntax.html#t:Info documentation], when reifying value variables "returning the RHS has not yet been implemented because of lack of interest". I'd like to formally request interest since I don't see a ticket here (may have missed it). My motivating example is to make source available for documentation and better error messages. Something like: {{{#!hs printSource :: Name -> Q Exp printSource n = do VarI _ _ (Just dec) <- reify n lift $ pprint dec foo x = x * 2 fooSource = $(printSource 'foo) -- === "\x_0 -> x_0 GHC.Num.* 2" }}} How significant of a change is this? I could take a pass at it if pointed to the relevant bits, having not contributed to GHC before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 15:42:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 15:42:23 -0000 Subject: [GHC] #14475: Upload documentation dumps Message-ID: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> #14475: Upload documentation dumps -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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: -------------------------------------+------------------------------------- Having a nightly job that would update https://downloads.haskell.org/~ghc/master/users-guide/ would be lovely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 16:44:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 16:44:46 -0000 Subject: [GHC] #14474: reify RHS of "value" variable In-Reply-To: <048.71df88e13081a2901e79c4bd24859fe9@haskell.org> References: <048.71df88e13081a2901e79c4bd24859fe9@haskell.org> Message-ID: <063.c6d68a89327779d12b35dd0d045accf8@haskell.org> #14474: reify RHS of "value" variable -------------------------------------+------------------------------------- Reporter: dailectic | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.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 goldfire): I don't think this will be so easy. GHC doesn't store the RHS of definitions in a convenient form to be reified into TH. Specifically, when GHC does store the RHS (only for inlinable definitions), it stores it in Core, not Haskell. So part of this work would be translating Core back to Haskell (not impossible). It actually might make a nice project... but the TH AST you get out at the end might not look much like what the user typed in originally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 16:52:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 16:52:10 -0000 Subject: [GHC] #14460: Can't decompose ghc.exe path In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.db25f691481d6cae5316a2c56e9b5e12@haskell.org> #14460: Can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | 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 Phyx-): What kind of drive is your `H:\` drive? just a normal harddisk? what's the OS and file system of the drive? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 17:00:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 17:00:06 -0000 Subject: [GHC] #14474: reify RHS of "value" variable In-Reply-To: <048.71df88e13081a2901e79c4bd24859fe9@haskell.org> References: <048.71df88e13081a2901e79c4bd24859fe9@haskell.org> Message-ID: <063.7c6d2b06edf343f1d6c21fafc207c1ef@haskell.org> #14474: reify RHS of "value" variable -------------------------------------+------------------------------------- Reporter: dailectic | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.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 dailectic): Actually I wouldn't mind just having access to core. Aren't definitions "inlinable" within their own module, or is intra-module inlining handled totally differently? It seems reasonable to only work where core is normally in scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 17:01:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 17:01:44 -0000 Subject: [GHC] #14476: Keep source locations in Core (optionally) Message-ID: <046.3e365eca3e9b79438172f03c5a0fd639@haskell.org> #14476: Keep source locations in Core (optionally) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.3 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 people working on liquid haskell have to maintain their own copy of the desugarer because of one little change they have to do: Add lots and lots of `CC`s to keep source spans around. Their current patch is {{{ diff --git a/src/Language/Haskell/Liquid/Desugar/DsExpr.hs b/src/Language/Haskell/Liquid/Desugar/DsExpr.hs index 396095e9a..9ba60c56f 100644 --- a/src/Language/Haskell/Liquid/Desugar/DsExpr.hs +++ b/src/Language/Haskell/Liquid/Desugar/DsExpr.hs @@ -221,14 +221,13 @@ dsUnliftedBind bind body = pprPanic "dsLet: unlifted" (ppr bind $$ ppr body) dsLExpr :: LHsExpr Id -> DsM CoreExpr dsLExpr (L loc e) - = putSrcSpanDs loc $ - do { core_expr <- dsExpr e - -- uncomment this check to test the hsExprType function in TcHsSyn - -- ; MASSERT2( exprType core_expr `eqType` hsExprType e - -- , ppr e <+> dcolon <+> ppr (hsExprType e) $$ - -- ppr core_expr <+> dcolon <+> ppr (exprType core_expr) ) - ; return core_expr } + = do ce <- putSrcSpanDs loc $ dsExpr e + m <- getModule + return $ Tick (srcSpanTick m loc) ce +srcSpanTick :: Module -> SrcSpan -> Tickish a +srcSpanTick m loc + = ProfNote (AllCafsCC m loc) False True -- | Variant of 'dsLExpr' that ensures that the result is not levity -- polymorphic. This should be used when the resulting expression will -- be an argument to some other function. }}} It would make their live easier if they could just use GHC’s desugarer, and it might open the path to making Liquid Haskell a proper GHC plugin instead of a separate program, which could facilitate adoption. Would it be ok to add a flag to GHC that enables this behaviour? Or is there another way of doing this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 17:06:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 17:06:11 -0000 Subject: [GHC] #14474: reify RHS of "value" variable In-Reply-To: <048.71df88e13081a2901e79c4bd24859fe9@haskell.org> References: <048.71df88e13081a2901e79c4bd24859fe9@haskell.org> Message-ID: <063.ce64b83566b33aef87a60492fff153eb@haskell.org> #14474: reify RHS of "value" variable -------------------------------------+------------------------------------- Reporter: dailectic | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.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 goldfire): The problem is that Core doesn't match up with TH syntax. I suppose it really just could return Core, without translating to the TH AST. I'm not sure off the top of my head if all local definitions are inlinable. It wouldn't be hard to experiment and find out, though. GHC also supports cross-module inlining, so there is a chance to work with non-local definitions. The code in question is all in the typecheck/TcSplice module. If you follow the types, this might not be so hard to do, after all. The definitions you're looking for, by the way, are in the `Unfolding` field of the `IdInfo` field of an `Id`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 17:13:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 17:13:58 -0000 Subject: [GHC] #14460: Can't decompose ghc.exe path In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.d298ccb9f2e97a66d5aa218ad4c099cd@haskell.org> #14460: Can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | 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 astert): I believe it's an external drive on a server. This is a school computer, and each student here has their own H drive when they log into one of the computers. I'm not sure about OS and file system. How do I figure that out? The computer is running windows 7, if that's what you mean. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 17:27:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 17:27:29 -0000 Subject: [GHC] #14474: reify RHS of "value" variable In-Reply-To: <048.71df88e13081a2901e79c4bd24859fe9@haskell.org> References: <048.71df88e13081a2901e79c4bd24859fe9@haskell.org> Message-ID: <063.c03757752e3dcb4894ea517c0107c31a@haskell.org> #14474: reify RHS of "value" variable -------------------------------------+------------------------------------- Reporter: dailectic | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.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 dailectic): Thanks for the pointer, I'll do some digging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 17:51:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 17:51:48 -0000 Subject: [GHC] #14476: Keep source locations in Core (optionally) In-Reply-To: <046.3e365eca3e9b79438172f03c5a0fd639@haskell.org> References: <046.3e365eca3e9b79438172f03c5a0fd639@haskell.org> Message-ID: <061.e9e77084c56e6d1080bfa9837cf8b3fe@haskell.org> #14476: Keep source locations in Core (optionally) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): Can they not use `SourceNote` ticks instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 20:07:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 20:07:40 -0000 Subject: [GHC] #14476: Keep source locations in Core (optionally) In-Reply-To: <046.3e365eca3e9b79438172f03c5a0fd639@haskell.org> References: <046.3e365eca3e9b79438172f03c5a0fd639@haskell.org> Message-ID: <061.8118cfeed858439439caaa8aa166de20@haskell.org> #14476: Keep source locations in Core (optionally) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 nomeata): I admit that I did not scrutinize the patch, nor do I personally know much about the various ticks. So feel free to phrase your input as propositions, not questions :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 20:21:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 20:21:15 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.6d5d4980d4f546745dad6a8c8205630c@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.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 cornuz): Any progress on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 20:42:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 20:42:41 -0000 Subject: [GHC] #14477: the 'impossible' happened, initTc: unsolved constraints Message-ID: <045.ad9160da3dde43c2a2f720d12bcba8fd@haskell.org> #14477: the 'impossible' happened, initTc: unsolved constraints --------------------------------------+--------------------------------- Reporter: bmusin | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 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: --------------------------------------+--------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 20:45:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 20:45:40 -0000 Subject: [GHC] #14477: the 'impossible' happened, initTc: unsolved constraints In-Reply-To: <045.ad9160da3dde43c2a2f720d12bcba8fd@haskell.org> References: <045.ad9160da3dde43c2a2f720d12bcba8fd@haskell.org> Message-ID: <060.e6acc901050c0194721585b36a165505@haskell.org> #14477: the 'impossible' happened, initTc: unsolved constraints ---------------------------------+-------------------------------------- Reporter: bmusin | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 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: | ---------------------------------+-------------------------------------- Old description: New description: Compile simple program using stack: stack ghc Main.hs code: import Control.Monad.Writer.Strict logNumber :: Int -> Writer [String] Int logNumber x = Writer (x, ["Got number: " ++ show x]) multWithLog :: Writer [String] Int multWithLog = do a <- logNumber 3 b <- logNumber 5 tell ["Gonnay multiply these two"] return (a*b) [1 of 1] Compiling Main ( Main.hs, Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] Writer_a19y :: t_a19x[tau:1] (CHoleCan: Writer)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Comment (by bmusin): Completed ticked description, initially submitted incomplete bug by mistake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 20:47:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 20:47:49 -0000 Subject: [GHC] #14477: the 'impossible' happened, initTc: unsolved constraints In-Reply-To: <045.ad9160da3dde43c2a2f720d12bcba8fd@haskell.org> References: <045.ad9160da3dde43c2a2f720d12bcba8fd@haskell.org> Message-ID: <060.6be849f215dd6a0fd225c0ed309f5c4b@haskell.org> #14477: the 'impossible' happened, initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: bmusin | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bmusin): * failure: None/Unknown => Compile-time crash or panic Comment: Add type of failure -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 21:15:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 21:15:31 -0000 Subject: [GHC] #14477: the 'impossible' happened, initTc: unsolved constraints In-Reply-To: <045.ad9160da3dde43c2a2f720d12bcba8fd@haskell.org> References: <045.ad9160da3dde43c2a2f720d12bcba8fd@haskell.org> Message-ID: <060.bc3d1d72c8bed328e255251fff99923f@haskell.org> #14477: the 'impossible' happened, initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: bmusin | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13106 Old description: > Compile simple program using stack: stack ghc Main.hs > > code: > import Control.Monad.Writer.Strict > > logNumber :: Int -> Writer [String] Int > logNumber x = Writer (x, ["Got number: " ++ show x]) > > multWithLog :: Writer [String] Int > multWithLog = do > a <- logNumber 3 > b <- logNumber 5 > tell ["Gonnay multiply these two"] > return (a*b) > > [1 of 1] Compiling Main ( Main.hs, Main.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.0.2 for x86_64-unknown-linux): > initTc: unsolved constraints > WC {wc_insol = [W] Writer_a19y :: t_a19x[tau:1] (CHoleCan: Writer)} > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: Compile simple program using stack: stack ghc Main.hs code: {{{#!hs import Control.Monad.Writer.Strict logNumber :: Int -> Writer [String] Int logNumber x = Writer (x, ["Got number: " ++ show x]) multWithLog :: Writer [String] Int multWithLog = do a <- logNumber 3 b <- logNumber 5 tell ["Gonnay multiply these two"] return (a*b) }}} {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] Writer_a19y :: t_a19x[tau:1] (CHoleCan: Writer)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Comment: Thanks for the bug report. This is a duplicate of #13106, and has been fixed in GHC 8.2: {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:4:15: error: • Data constructor not in scope: Writer :: (Int, [[Char]]) -> Writer [String] Int • Perhaps you meant one of these: ‘WriterT’ (imported from Control.Monad.Writer.Strict), variable ‘writer’ (imported from Control.Monad.Writer.Strict) | 4 | logNumber x = Writer (x, ["Got number: " ++ show x]) | ^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 21:41:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 21:41:19 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.0f6cb49360d276fb6412d1ebb9e92152@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.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): It's not clear to me whether DanielG actually solved his issue or not. The ticket is still open so presumably not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 21:44:04 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 21:44:04 -0000 Subject: [GHC] #14476: Keep source locations in Core (optionally) In-Reply-To: <046.3e365eca3e9b79438172f03c5a0fd639@haskell.org> References: <046.3e365eca3e9b79438172f03c5a0fd639@haskell.org> Message-ID: <061.205863c5db390d1b9346aac5713596a4@haskell.org> #14476: Keep source locations in Core (optionally) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): Okay: I recommend they use `SourceNote`s instead of cost centers ;) That being said, we don't offer a terribly great way to communicate to GHC that it should add source notes. The only way currently is `-g` (corresponding to the `debugLevel` `DynFlags` field) however it also controls code generation so it may not be appropriate for a plugin. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 22:11:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 22:11:55 -0000 Subject: [GHC] #14476: Keep source locations in Core (optionally) In-Reply-To: <046.3e365eca3e9b79438172f03c5a0fd639@haskell.org> References: <046.3e365eca3e9b79438172f03c5a0fd639@haskell.org> Message-ID: <061.bc623141f87cdacc43f791d5fd118e78@haskell.org> #14476: Keep source locations in Core (optionally) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 nomeata): > we don't offer a terribly great way to communicate to GHC that it should add source notes. But a patch that adds a flag to do so would be reasonable, woundn’t it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 22:52:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 22:52:41 -0000 Subject: [GHC] #14476: Keep source locations in Core (optionally) In-Reply-To: <046.3e365eca3e9b79438172f03c5a0fd639@haskell.org> References: <046.3e365eca3e9b79438172f03c5a0fd639@haskell.org> Message-ID: <061.9e67ecb59cce17dfd3e13b1ce8203d37@haskell.org> #14476: Keep source locations in Core (optionally) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): What semantics would this flag have? Just enable tick generation in desugar without enabling any of the codegen bits? There are a few questions: Should ticks be preserved in interface files in this case? STG? C--? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 23:12:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 23:12:01 -0000 Subject: [GHC] #14255: Type-indexed type fingerprints In-Reply-To: <045.c1ec2f0ceaf2c14abbc2ecd752ef0c71@haskell.org> References: <045.c1ec2f0ceaf2c14abbc2ecd752ef0c71@haskell.org> Message-ID: <060.7a02541bda0a00ec0d965e2e2ffa1479@haskell.org> #14255: Type-indexed type fingerprints -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable 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 dfeuer): Whether or not we can reduce the size of the trusted code base, I think this is a good thing to offer. In particular, applications that use deserialized `Dynamic` very heavily, but that ''don't'' use `dynApply` or other reflection-based operations can be much more efficient if they stick to fingerprints instead of full `TypeRep`s. Indexing these fingerprints by type supports a friendly and modern, though necessarily limited, API. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 16 23:24:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Nov 2017 23:24:26 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.2216346c76ebdca356099aff58d34ff4@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.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 DanielG): * Attachment "LeakyResetStringTable2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 00:57:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 00:57:55 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.3802a19c7e33af2d5366d087f3dff8eb@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.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 DanielG): * Attachment "ghc-expose-string-table.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 01:09:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 01:09:12 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.467943fca4d11b15d9a16c837b37060c@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.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 DanielG): * Attachment "LeakyResetStringTable2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 01:09:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 01:09:12 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.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 DanielG): * Attachment "LeakyResetStringTable2.hs" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 01:10:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 01:10:15 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.b4c539386ed1df229426661cc5522676@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.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 DanielG): I just tried with master (c7297342a4) and the ghc-8.2 branch (befd937353) and I can still reproduce this. As I said above resetting the string table doesn't seem to improve the steady state memory usage at all. I made the test case a little easier to use and I'm including the patch I used to expose the `string_table`. With `ghc-expose-string-table.patch` applied you can reproduce this in a GHC source tree like so: {{{ $ ./inplace/bin/ghc-stage2 -package ghc LeakyResetStringTable2.hs -rtsopts -with-rtsopts=-T $ ./LeakyResetStringTable gcdetails_live (MB): 0.443450927734375 gcdetails_mem_in_use (MB): 81.0 VmData (MB): 246.2578125 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 01:17:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 01:17:24 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.8dd7b53d0852ded91ed91b2107bf0cb8@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by DanielG): * version: 8.0.2 => 8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 06:44:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 06:44:20 -0000 Subject: [GHC] #14478: Abstract pattern synonyms (for hsig and hs-boot) Message-ID: <045.8d2821cb171cb8f59be6aa602942a2eb@haskell.org> #14478: Abstract pattern synonyms (for hsig and hs-boot) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Most declaration forms (data types, values, type families, etc) support forward declaration in hs-boot/hsig files. However, pattern synonyms do not. This seems like a major omission! Some problems to solve: * The obvious syntax `pattern Foo :: pat_ty` is insufficient to specify whether or not a pattern is bidirectional or unidirectional. How should this be represented syntactically? * What is the interaction with bundling? Should it be possible to export a bundle of abstract pattern synonyms, with the intent that this means an implementation must also have bundled them together * See also #12717; abstract pattern synonym should be implementable with a plain old constructor -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 08:42:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 08:42:17 -0000 Subject: [GHC] #14478: Abstract pattern synonyms (for hsig and hs-boot) In-Reply-To: <045.8d2821cb171cb8f59be6aa602942a2eb@haskell.org> References: <045.8d2821cb171cb8f59be6aa602942a2eb@haskell.org> Message-ID: <060.de39a02c824cec3bbc3d204c9aad2062@haskell.org> #14478: Abstract pattern synonyms (for hsig and hs-boot) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | 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 ezyang): OK, so there is a major wrinkle: pattern-synonym signature splitting. The problem is described in this note: {{{ Note [The pattern-synonym signature splitting rule] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Given a pattern signature, we must split the kind-generalised variables, and the implicitly-bound variables into universal and existential. The rule is this (see discussion on Trac #11224): The universal tyvars are the ones mentioned in - univ_tvs: the user-specified (forall'd) universals - req_theta - res_ty The existential tyvars are all the rest For example pattern P :: () => b -> T a pattern P x = ... Here 'a' is universal, and 'b' is existential. But there is a wrinkle: how do we split the arg_tys from req_ty? Consider pattern Q :: () => b -> S c -> T a pattern Q x = ... This is an odd example because Q has only one syntactic argument, and so presumably is defined by a view pattern matching a function. But it can happen (Trac #11977, #12108). We don't know Q's arity from the pattern signature, so we have to wait until we see the pattern declaration itself before deciding res_ty is, and hence which variables are existential and which are universal. And that in turn is why TcPatSynInfo has a separate field, patsig_implicit_bndrs, to capture the implicitly bound type variables, because we don't yet know how to split them up. It's a slight compromise, because it means we don't really know the pattern synonym's real signature until we see its declaration. So, for example, in hs-boot file, we may need to think what to do... (eg don't have any implicitly-bound variables). }}} One way we could manage this without introducing a new syntactic construct is to have a user specify both pattern synonym signature AND a stub declaration, literally writing something like: {{{ pattern P :: () => b -> T a pattern P x = ... }}} That's a literal `...`, because if we introduce this syntax, we now can also solve the problem of unidirectional versus bidirectional; to declare only a unidirectional pattern is required, you write: {{{ pattern P :: () => b -> T a pattern P x <- ... }}} It's annoyingly asymmetric with how we do regular value signatures, but the alternative seems worse (inventing a new signature syntax which builds in the arity somehow.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 16:13:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 16:13:22 -0000 Subject: [GHC] #14479: Partial type signatures and generalisation Message-ID: <046.dc08a3c3d392ce3db896a2149215fdcd@haskell.org> #14479: Partial type signatures and generalisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 should be rejected {{{ foo :: Num a => a -> a foo x = g x x where g :: Num b => _ -> b -> b g _ y = x + y }}} But it isn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 16:18:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 16:18:05 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.1d26ac04b1943ac30837063f7b487996@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13497, 13525 | Blocking: Related Tickets: #12912, #13525 | Differential Rev(s): Phab:D42 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I managed to make it work on Windows for `FILE_TYPE_CHAR`, by using `WaitForMultipleObjects()` and passing it 2 objects: The `HANDLE` we're interested in, an Event object that we signal when we want to interrupt the thread. After searching for a very long time, I ended up with the above solution. Most important links: * [https://social.msdn.microsoft.com/Forums/sqlserver/en- US/dd7ce0e9-847d-4727-b0a6-efd68bd5626e/synchronous-readfile-on-stdin- cannot-be-unblocked-by-cancelsynchronousio?forum=windowssdk Post by Ben Golding in this thread] that proposes this solution * [https://stackoverflow.com/questions/47336755/how-to- cancelsynchronousio-on-waitforsingleobject-waiting-on-stdin My StackOverflow question] (answers trickled in only after I had already implemented a work-in-progress solution Here's the backstory of me finding it out via the `#ghc` and `#winapi` IRC channels: In `#ghc`: {{{ JaffaCake_: may I steal your attention for a minute? `ccall interruptible` doesn't seem to work for me on Windows, it claims that there's nothing to cancel, do you have an idea what this could be? https://ghc.haskell.org/trac/ghc/ticket/8684#comment:25 no idea, sorry there was a bug reported recently in process that also looks like foreign ccall interruptible not working on windows JaffaCake_: yes, I'm aware of it and have talked a bit with Neil about it, I'll try to make that interruptible after I've made hWaitForInput interruptible (already works on Linux -threaded for me), but currently it seems interruptible doesn't work at all for me on Windows TBH I don't remember whether it ever worked JaffaCake_: there's another thing that I've already looked into a couple hours but haven't found a way yet: My non-Windows fix works nicely on -threaded, but for nonthreaded it doesn't, because the scheduler makes it immediately re- enter the foreign call, so the `throwTo` in `timeout` doesn't get a chance to run. Would it be possible to say, in the scheduler: Whenever a thread returns from a foreign call, yield, so that other Haskell threads have a chance to run? I think that's probably a bad idea if the timeout has fired, then there should be a blocked exception and that should get thrown immediately the FFI call returns hWaitForInput/fdReady() gets woken up by the SIGVTALRM timer signal, and then the scheduler immediately runs fdReady() again so `timeout` never actually gets a chance to throwTo the exception so in other words, the timeout can never fire nh2[m], you're not running with -threaded? JaffaCake_: no, that's what I meant, it's working fine with -threaded on Linux, but not with non-threaded. This problem (and my question on whether we could yield after FFI return) is only for non- threaded oh, I'm not worried about non-threaded JaffaCake_: but I am :D I'm trying to make it work equally well across both threaded and non-threaded; in general I care a lot about non-threaded as for some applications it is significantly faster, and it is also easier to debug but you'll need to add hacks to make it work, hacks that could add overhead for -threaded JaffaCake_: my hope is that such overhead would be negligible, as it would occur only for `interruptible` syscalls (which by nature are expensive, so a bit of bookkeeping around them should not matter much). For example, all calls to `fdReady()` that are performance- sensitive, nonblocking (timeout=0), already use `unsafe` and thus wouldn't suffer any overhead having non-threaded not working would be quite a drag for us, as we found it to perform way better for sequential-IO-heavy (e.g. network) code and with things like `timeout` not working for `hWaitForInput`, we can't put timeouts on reads or writes in high-level the code (would have to handle such logic at the very low level of hWaitForInput itself) e.g. `timeout N $ seriesOfVariousNetworkProtocolActions` }}} In `#winapi`: {{{ nh2 18:54 hi, I'm trying to WaitForSingleObject(GetStdHandle(STD_INPUT_HANDLE), ...) on stdin, and to cancel this waiting using CancelSynchronousIo(), but the cancellation does nothing (returns 0 and GetLastError() is ERROR_NOT_FOUND). Any idea what I could be doing wrong? SleepyISIS (IRC) 19:29 nh2[m]: If this function cannot find a request to cancel, the return value is 0 (zero), and GetLastError returns ERROR_NOT_FOUND. 19:30 Are you sure that you want to cancel IO, not the wait itself? nh2 19:31 SSleepyISIS: can you elaborate a bit on that distinction? To me those sound like the same things 19:33 what I need to do is use a function that blocks until input is available on the given HANDLE to a FILE_TYPE_CHAR, up to a maximum amount of time (e.g. in milliseconds), but if some other event occurs, I need to cancel that blocking wait John___ (IRC) 19:33 nh2[m], there's SleepEx() 19:34 which does what you want. 19:35 also WaitForMultiple/SingleObject() 19:35 depends what your goal is. nh2 19:35 JJohn___: that one seems to just wait a given amount of time, independent from input being available on some HANDLE. I want to wait until either the specified time has passed, or there's input available on the HANDLE, or the waiting has been cancelled (e.g. using CancelSynchronousIO) SleepyISIS (IRC) 19:35 nh2[m]: Is terminating a thread an option? John___ (IRC) 19:36 nh2[m], then WaitForSingleObject() nh2 19:37 JJohn___: yes, that is what I am using, and what doesn't seem to work (as I wrote above) SleepyISIS (IRC) 19:37 Or stick to asynch solution. John___ (IRC) 19:37 it waits for a timeout or when input is available on a handle. 19:37 I was not here to see what the problem was. mind pasting it again? nh2 19:37 SSleepyISIS: regarding terminating a thread, likely not, it should ideally work in a single-threaded use case (I'm doing this for an improvement in the GHC Haskell compiler), but I would still very much like to hear what you have in mind, maybe it is possible SleepyISIS (IRC) 19:38 John___: If I got nh2[m] correctly, (s)he wants to abort synch IO before the wait timeouts. nh2 19:38 JJohn___: I've just written up the problem more clearly on https://stackoverflow.com/questions/47336755/how-to-cancelsynchronousio- on-waitforsingleobject-waiting-on-stdin How to CancelSynchronousIo() on WaitForSingleObject() waiting on stdin? On Windows 10, I'm waiting for input from the console using WaitForSingleObject( GetStdHandle(STD_INPUT_HANDLE), ... ) and to cancel this waiting using CancelSynchronousIo(). But the cancellatio... SleepyISIS (IRC) 19:39 nh2[m]: https://stackoverflow.com/questions/34372611/how-to-signal- file-handle-waiting-with-waitforsingleobject How to signal file HANDLE waiting with WaitForSingleObject This code, which I have no control over, reads a file using overlapped I/O: // Read file asynchronously HANDLE hFile = CreateFile(..., FILE_FLAG_OVERLAPPED, ...); BYTE buffer[10]; OVERLAPPED oRead... 19:39 Hmm, what value do you get from GetStdHandle? John___ (IRC) 19:40 nh2[m], synchronous solutions cannot be "unblocked" 19:40 that's why you use async. 19:40 let me read the stack post first though before I reply differently. nh2 19:42 JJohn___: it was my understanding so far that CancelSynchronousIo()'s purpose is to cancel specifically functions like WaitForSingleObject(), so I'm surprised that it doesn't work John___ (IRC) 19:42 I don't think it's for those purposes. nh2 19:42 SSleepyISIS: the HANDLE returned from GetStdHandle() is 0 for the stdin SleepyISIS (IRC) 19:43 >My colleague suggested WaitForMultipleObjects() as a workaround. So we can wait on either the console/stdin handle or an event which signals termination. 19:43 Good solution. 19:43 0 doesn't seem to be a valif handle. 19:44 Yeah: If an application does not have associated standard handles, such as a service running on an interactive desktop, and has not redirected them, the return value is NULL. 19:44 https://docs.microsoft.com/en-us/windows/console/getstdhandle John___ (IRC) 19:44 yeah, that ^ 19:45 using that in combination with SetEvent() 19:45 allows you to either make WaitForMultipleObjects() to catch on WAIT_SIGNALED or WAIT_TIMEOUT nh2 19:45 SSleepyISIS: oh sorry, I typoed my printf. The HANDLE returned from GetStdHandle() is 84 for the stdin John___ (IRC) 19:45 or whatevet 19:45 so you can make it either trigger when the handle input is available nh2 19:48 SSleepyISIS: JJohn___ OK, so I would get rid of the CancelSynchronousIo() completely, and always make sure that any WaitForSingleObject() on stdin is instead a WaitForMultipleObjects() on stdin AND the special separate event handle I use for "early termination" of the wait? Mysoft (IRC) 19:50 nh2[m] 19:50 you tried to use CancelIoEx 19:50 isntead of CancelIoSynchronous? nh2 19:55 MMysoft: I will try that now; what would you pass as the lpOverlapped argument, NULL? Mysoft (IRC) 19:56 yeah 19:56 and which OS you are trying that? 19:56 and you're running from console? 19:56 or inside an IDE? nh2 19:57 MMysoft: that call fails with GetLastError() == 6 (ERROR_INVALID_HANDLE). I'm on Windows 10, running from cmd.exe Mysoft (IRC) 19:58 ok 19:58 so this was a behavior change 19:58 because here it works 19:58 i think it changes in some update on win7 19:58 (bug?) 19:59 there's a OldNewThing about the subject 19:59 https://blogs.msdn.microsoft.com/oldnewthing/20150323-00/?p=44413 20:00 but anyway using WaitForMultipleObjects is the way to go 20:00 as i think using CancelIoEx... looks as bad as "ungetc" :P nh2 20:04 MMysoft: ah wait, I am using CancelIoEx() wrong. For the CancelSynchronousIo() I had to provide a thread handle as an argument, but for CancelIoEx() I have to provide the actual file handle as the argument. Let me retry 20:05 nh2 20:06 MMysoft: OK, with that fixed, CancelIoEx() gives me GetLastError() == ERROR_NOT_FOUND, like for CancelSynchronousIo() 20:07 I'll try the oldnewthing example code on my system [Note by nh2: I didn't actually manage to make that compile immediately with msys, and it didn't turn out to be necessary to solve the issue] John___ (IRC) 20:46 nh2[m], yes, you pass 2 handles and you check which got signaled. 20:46 the result is WAIT_OBJECT_0 to (WAIT_OBJECT_0 + nCount– 1) nh2 00:11 JJohn__: SSleepyISIS MMysoft : thanks for your help, I just got the first working implementation for GHC that fixes its behaviour on Windows, using your proposed extra event + WaitForMultipleObjects() approach! }}} Back in `#ghc`: {{{ JaffaCake: I think I have finally figured out how to fix the Windows problem with CancelSynchronousIo() having no effect. Some people on #winapi helped me, saying that this function might not work in practice and instead we could use WaitForMultipleObjects(), with 2 objects, one for the actual FD HANDLE and one Event we'd signal if we want WaitForMultipleObjects() to return early. I've coded that up and it works. But for efficiency, I need one Event per thread, so that I don't wake up all threads in `interruptWorkerTask()`, but only the target one. My plan is thus to have a `HANDLE interruptOSThreadEvent;` in the `struct Task` But I need to access that in `inputReady.c`, which is in base, where I cannot get at the currently running task with `myTask()` is there a way I can ask for the currently running Haskell task from that location? I'm pretty sure we do that in integer-gmp JaffaCake: I don't know how thread-local storage actually works internally, but I suppose it's done by symbol names somehow, and if I just declare `extern __thread Task *my_task;` in `inputReady.c`, it would refer to the right thing technically? (though I'd still have to bring `Task` into scope) just expose a function from the RTS to return the thread- local Event I was thinking of rts_unsafeGetMyCapability() which is a similar kind of thing JaffaCake: which would be the best header file to put it in? Probably somewhere under `includes/rts`? next to rts_unsafeGetMyCapability() JaffaCake: OK, and it would have to go somewhere in RtsSymbols.c, probably `RTS_MINGW_ONLY_SYMBOLS`, is that right? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 19:48:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 19:48:55 -0000 Subject: [GHC] #14476: Keep source locations in Core (optionally) In-Reply-To: <046.3e365eca3e9b79438172f03c5a0fd639@haskell.org> References: <046.3e365eca3e9b79438172f03c5a0fd639@haskell.org> Message-ID: <061.e8e16b175b3c3e1244b1b55d1d0dfd00@haskell.org> #14476: Keep source locations in Core (optionally) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Niki): So, @bgamari you are saying that if I run ghc with a hight enough `debugLevel` (is it just >2?), than CoreExpr will preserve all source info as `SourceNote` (inside the Ticks). I will try it in LH to see if it work, but for completeness, this is related to https://ghc.haskell.org/trac/ghc/ticket/10506 (that seem to be stale) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 19:49:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 19:49:55 -0000 Subject: [GHC] #14480: Clean up tyConTYPE Message-ID: <045.40a9ead57879cd86037390fff41509af@haskell.org> #14480: Clean up tyConTYPE -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Core | Version: 8.2.1 Libraries | Keywords: Typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Phab:4085 builds a `TyCon` representing `TYPE` by hand in `Data.Typeable.Internal`. This is pretty disgusting, but it was the only way I managed to smash the last of the mysterious loops. It would be very nice to find a cleaner way, but we want to get that merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 20:16:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 20:16:16 -0000 Subject: [GHC] #14476: Keep source locations in Core (optionally) In-Reply-To: <046.3e365eca3e9b79438172f03c5a0fd639@haskell.org> References: <046.3e365eca3e9b79438172f03c5a0fd639@haskell.org> Message-ID: <061.c6d01fbfee6dc745a3e1f4b212f5209e@haskell.org> #14476: Keep source locations in Core (optionally) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 mpickering): Yes, setting `debugLevel` to 2 is exactly what `-g` does. Setting it to 1,2 or 3, it doesn't matter as they all do the same thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 21:25:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 21:25:49 -0000 Subject: [GHC] #14255: Type-indexed type fingerprints In-Reply-To: <045.c1ec2f0ceaf2c14abbc2ecd752ef0c71@haskell.org> References: <045.c1ec2f0ceaf2c14abbc2ecd752ef0c71@haskell.org> Message-ID: <060.e2ca850e75f810d134679aa4875212b0@haskell.org> #14255: Type-indexed type fingerprints -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable 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 dfeuer): Just so I don't lose the idea, we can implement a `Typeable`-alike for such fingerprints that leverages the existing `Typeable` infrastructure but avoids the cost of manipulating any more `TypeRep`s than necessary: {{{#!hs data FingerprintIx (a :: k) appFingerprintIx :: forall j k (f :: j -> k) (x :: j). FingerprintIx f -> FingerprintIx x -> FingerprintIx (f x) appFingerprintIx _ _ = undefined funFingerprintIx :: forall r1 r2 (arg :: TYPE r1) (res :: TYPE r2). FingerprintIx arg -> FingerprintIx res -> FingerprintIx (arg -> res) funFingerprintIx _ _ = undefined foo :: TypeRep a -> FingerprintIx a foo _ = undefined class HasFingerprintIx (a :: k) where fpi :: FingerprintIx a data Expr where Base :: Expr FunE :: Expr -> Expr -> Expr AppE :: Expr -> Expr -> Expr type family From (a :: k) :: Expr where From (a -> b) = 'FunE (From a) (From b) From (f x) = 'AppE (From f) (From x) From x = 'Base class HasFingerprintIx' (e :: Expr) (a :: k) where fpi' :: FingerprintIx a instance Typeable a => HasFingerprintIx' 'Base a where fpi' = foo typeRep instance (HasFingerprintIx' e1 f, HasFingerprintIx' e2 x) => HasFingerprintIx' ('AppE e1 e2) ((f :: j -> k) x) where fpi' = appFingerprintIx (fpi' @_ @e1) (fpi' @_ @e2) instance (HasFingerprintIx' e1 arg, HasFingerprintIx' e2 res) => HasFingerprintIx' ('FunE e1 e2) ((arg :: TYPE r1) -> (res :: TYPE r2)) where fpi' = funFingerprintIx (fpi' @_ @e1) (fpi' @_ @e2) instance (e ~ From a, HasFingerprintIx' e a) => HasFingerprintIx (a :: k) where fpi = fpi' @_ @e }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 21:29:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 21:29:41 -0000 Subject: [GHC] #14372: CMM contains a bunch of tail-merging opportunities In-Reply-To: <048.1c543d9c1482e4763ed7a0bf48a66309@haskell.org> References: <048.1c543d9c1482e4763ed7a0bf48a66309@haskell.org> Message-ID: <063.1023bac07230b3636bf214a5d3308c01@haskell.org> #14372: CMM contains a bunch of tail-merging opportunities -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 nomeata): * cc: nomeata (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 22:05:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 22:05:52 -0000 Subject: [GHC] #14481: Mutually dependent modules with orphan instances causes missing symbols with single-shot compilation Message-ID: <046.537d69b8076d6f4e322b5c70e81602cf@haskell.org> #14481: Mutually dependent modules with orphan instances causes missing symbols with single-shot compilation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (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: -------------------------------------+------------------------------------- Alan Zimmerman encountered this nasty bug in his Trees That Grow branch: Consider we have the following types, {{{#!hs module Types where data Expr p = Var String | App (Expr p) (Expr p) | ADecl (Decl p) data Decl p = Bind String (Expr p) }}} Now imagine that for some reason we want to define orphan instances for some class (`Show`, for instance) for these types in two separate modules. We would have: {{{#!hs -- Instances1.hs module Instances1 where import {-# SOURCE #-} Instances2 () import Types deriving instance Show (Decl p) -- Instances1.hs-boot module Instances1 where import Types instance Show (Decl p) -- Instances2.hs module Instances2 where import {-# SOURCE #-} Instances1 () import Types deriving instance Show (Expr p) -- Instances2.hs-boot module Instances2 where import Types instance Show (Expr p) }}} Now, for instance, say we have some program that uses this whole mess, {{{#!hs -- Main.hs module Main where import Types -- Use SOURCE import to ensure GHC doesn't grab dictionary from unfolding in -- interface file import {-# SOURCE #-} Instances2 main = putStrLn $ show $ (Var "hi" :: Expr Int) }}} With `--make` mode we can compile `Main.hs` with no trouble: {{{ $ ghc --make Main.hs [1 of 6] Compiling Types ( Types.hs, Types.o ) [2 of 6] Compiling Instances2[boot] ( Instances2.hs-boot, Instances2.o-boot ) [3 of 6] Compiling Main ( Main.hs, Main.o ) [4 of 6] Compiling Instances1[boot] ( Instances1.hs-boot, Instances1.o-boot ) [5 of 6] Compiling Instances2 ( Instances2.hs, Instances2.o ) [6 of 6] Compiling Instances1 ( Instances1.hs, Instances1.o ) Linking Main ... $ ./Main Var "hi" }}} However, if we instead use single-shot mode, we end up never producing object code for one of the boot DFuns, {{{ $ ghc -c Types.hs $ ghc -c Instances1.hs-boot $ ghc -c Instances2.hs $ ghc -c Instances2.hs-boot $ ghc -c Instances1.hs $ ghc -c Main.hs $ ghc -o test Types.o Instances1.o Instances2.o Main.o Main.o:s1lN_info: error: undefined reference to 'Instances2_zdfxShowExpr_closure' Main.o(.data.rel.ro+0x8): error: undefined reference to 'Instances2_zdfxShowExpr_closure' collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) }}} In the case of `--make` mode the symbol in question is emitted in the object code for `Instances2`. However, when we use single-shot mode the `hi-boot` file for `Instances2` doesn't exist when the `hs` file is compiled. It seems that this makes the DFun impedance matching logic in `TcRnDriver.checkBootIface'` not fire. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 22:07:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 22:07:55 -0000 Subject: [GHC] #14481: Mutually dependent modules with orphan instances causes missing symbols with single-shot compilation In-Reply-To: <046.537d69b8076d6f4e322b5c70e81602cf@haskell.org> References: <046.537d69b8076d6f4e322b5c70e81602cf@haskell.org> Message-ID: <061.7645e8ba01aa6df1486c976869efb182@haskell.org> #14481: Mutually dependent modules with orphan instances causes missing symbols with single-shot compilation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 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 bgamari): * status: new => closed * resolution: => invalid Comment: Ahh, never mind; this is actually fine. The bug is actually one in the GHC build system (or perhaps GHC's `-M` mode). We need to ensure that we always compile a module's `hs-boot` file before its associated source file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 22:11:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 22:11:49 -0000 Subject: [GHC] #14482: GHC -M mode fails to ensure that boot files are built before source files Message-ID: <046.f887b8665019281d6519a59f53c32782@haskell.org> #14482: GHC -M mode fails to ensure that boot files are built before source files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Imagine we have a module with a boot file. In general it is necessary to ensure that we compile the boot file *before* the source file to ensure that the `hi-boot` file exists when we go to typecheck the module (triggering the behavior observed in #14481). However, `ghc -M` doesn't guarantee this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 22:13:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 22:13:18 -0000 Subject: [GHC] #14481: Mutually dependent modules with orphan instances causes missing symbols with single-shot compilation In-Reply-To: <046.537d69b8076d6f4e322b5c70e81602cf@haskell.org> References: <046.537d69b8076d6f4e322b5c70e81602cf@haskell.org> Message-ID: <061.dccd85573283d5314cba93af760bc096@haskell.org> #14481: Mutually dependent modules with orphan instances causes missing symbols with single-shot compilation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 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 bgamari): Indeed this is a bug in `ghc -M`. For instance {{{ $ ghc -c Instances2.hs $ cat Makefile # DO NOT DELETE: Beginning of Haskell dependencies Types.o : Types.hs Instances2.o-boot : Instances2.hs-boot Instances2.o-boot : Types.hi Main.o : Main.hs Main.o : Instances2.hi-boot Main.o : Types.hi Instances1.o-boot : Instances1.hs-boot Instances1.o-boot : Types.hi Instances2.o : Instances2.hs Instances2.o : Instances1.hi-boot Instances2.o : Types.hi Instances1.o : Instances1.hs Instances1.o : Instances2.hi-boot Instances1.o : Types.hi # DO NOT DELETE: End of Haskell dependencies }}} I believe GHC should have produced the following dependencies as well: {{{ Instances1.o : Instances1.hi-boot Instances2.o : Instances2.hi-boot }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 22:13:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 22:13:42 -0000 Subject: [GHC] #14481: Mutually dependent modules with orphan instances causes missing symbols with single-shot compilation In-Reply-To: <046.537d69b8076d6f4e322b5c70e81602cf@haskell.org> References: <046.537d69b8076d6f4e322b5c70e81602cf@haskell.org> Message-ID: <061.721addec490b46c998b763f215af43e2@haskell.org> #14481: Mutually dependent modules with orphan instances causes missing symbols with single-shot compilation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #14482 Comment: I've opened #14482 to track this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 22:13:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 22:13:51 -0000 Subject: [GHC] #14482: GHC -M mode fails to ensure that boot files are built before source files In-Reply-To: <046.f887b8665019281d6519a59f53c32782@haskell.org> References: <046.f887b8665019281d6519a59f53c32782@haskell.org> Message-ID: <061.dffa0cfc1fcc77cfb0dc36b0d5a988bb@haskell.org> #14482: GHC -M mode fails to ensure that boot files are built before source files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #14481 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 22:32:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 22:32:34 -0000 Subject: [GHC] #14372: CMM contains a bunch of tail-merging opportunities In-Reply-To: <048.1c543d9c1482e4763ed7a0bf48a66309@haskell.org> References: <048.1c543d9c1482e4763ed7a0bf48a66309@haskell.org> Message-ID: <063.b2d7adceb44247883e8683999421616b@haskell.org> #14372: CMM contains a bunch of tail-merging opportunities -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 jp.rider63): What's the status of this? I'd be interested in contributing to the implementation if it's helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 22:40:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 22:40:47 -0000 Subject: [GHC] #14372: CMM contains a bunch of tail-merging opportunities In-Reply-To: <048.1c543d9c1482e4763ed7a0bf48a66309@haskell.org> References: <048.1c543d9c1482e4763ed7a0bf48a66309@haskell.org> Message-ID: <063.7f5a65dada10a4ae9a2d675b03ec77a8@haskell.org> #14372: CMM contains a bunch of tail-merging opportunities -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 heisenbug): Replying to [comment:13 jp.rider63]: > What's the status of this? I'd be interested in contributing to the implementation if it's helpful. There is a branch in my GHC fork on github: https://github.com/ggreif/ghc/tree/wip/global-cmm-cbe It does not work with `ghc --make` because the assembly files contain local labels. Concatenating all assembly files might work, but I have not tried it yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 22:47:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 22:47:16 -0000 Subject: [GHC] #14481: Mutually dependent modules with orphan instances causes missing symbols with single-shot compilation In-Reply-To: <046.537d69b8076d6f4e322b5c70e81602cf@haskell.org> References: <046.537d69b8076d6f4e322b5c70e81602cf@haskell.org> Message-ID: <061.503028563926b962866a9928c1537f78@haskell.org> #14481: Mutually dependent modules with orphan instances causes missing symbols with single-shot compilation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The repro from which I deduced this can be found here: https://github.com/bgamari/T14481-repro -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 17 22:47:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Nov 2017 22:47:23 -0000 Subject: [GHC] #14482: GHC -M mode fails to ensure that boot files are built before source files In-Reply-To: <046.f887b8665019281d6519a59f53c32782@haskell.org> References: <046.f887b8665019281d6519a59f53c32782@haskell.org> Message-ID: <061.ac8305e9d80471d96d939a6a21e80c3d@haskell.org> #14482: GHC -M mode fails to ensure that boot files are built before source files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The repro from which I deduced this can be found here: https://github.com/bgamari/T14481-repro -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 01:05:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 01:05:53 -0000 Subject: [GHC] #14481: Mutually dependent modules with orphan instances causes missing symbols with single-shot compilation In-Reply-To: <046.537d69b8076d6f4e322b5c70e81602cf@haskell.org> References: <046.537d69b8076d6f4e322b5c70e81602cf@haskell.org> Message-ID: <061.99c6ca28e2af5deabcd9c1a5e19a431b@haskell.org> #14481: Mutually dependent modules with orphan instances causes missing symbols with single-shot compilation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): There may be more bugs along the lines of #14482. In general we require that hs-boot files are compiled before hs files. However, we aren't very good at checking this in single-shot mode. `tcHiBootIface` makes something of an attempt, but the logic there will fail if the compiler hasn't seen any SOURCE imports of the module being compiled (since the module will have no entry in `eps_is_boot`, leading `tcHiBootIface` to conclude that the module simply has no boot file). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 01:08:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 01:08:23 -0000 Subject: [GHC] #14482: GHC -M mode fails to ensure that boot files are built before source files In-Reply-To: <046.f887b8665019281d6519a59f53c32782@haskell.org> References: <046.f887b8665019281d6519a59f53c32782@haskell.org> Message-ID: <061.211cf8b066f7b454c97fb9bae86f8d44@haskell.org> #14482: GHC -M mode fails to ensure that boot files are built before source files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14481 | Differential Rev(s): Phab:D4208 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4208 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 02:10:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 02:10:50 -0000 Subject: [GHC] #14483: getExecutablePath from System.Environment in base should follow symlinks properly. Message-ID: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> #14483: getExecutablePath from System.Environment in base should follow symlinks properly. -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- During the implementation of relocation capabilities in GHC for linux and macOS it came to light, that windows (which has had this support for quite some time), uses a custom implementation of `getExecutablePath`. Ideally this logic should be moved into `base`. Phyx- noted in D4121 that this should be possible for 8.6, as at that point Win32 should be new enough to be usable in base for this. The result would be that the custom code in GHC (SysTools) and the older copy in GhcPkg of the same code can be unified with the linux and macOS CPP conditional branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 02:22:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 02:22:35 -0000 Subject: [GHC] #14484: GHC rejects use of mulit-param type class. Message-ID: <048.7b80256ede65b84a84caa9f7d57a06cc@haskell.org> #14484: GHC rejects use of mulit-param type class. -------------------------------------+------------------------------------- Reporter: trinithis | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the following example, I instantiate a few small typeclasses. The last instantiation provided does not compile, despite it being virtually identical the prior instantiation. {{{#!hs {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE MultiParamTypeClasses #-} -------------------------------------------------------------------------------- class Collection collection handle | collection -> handle, handle -> collection where getHandles :: collection -> [handle] -------------------------------------------------------------------------------- data HandleX = HandleX Int data CollectionX = CollectionX [HandleX] instance Collection CollectionX HandleX where getHandles (CollectionX handles) = handles -------------------------------------------------------------------------------- newtype HandleY = HandleY HandleX newtype CollectionY = CollectionY CollectionX instance Collection CollectionY HandleY where getHandles (CollectionY collectionX) = map HandleY $ getHandles collectionX -- Good, this compiles! -------------------------------------------------------------------------------- newtype HandleZ = HandleZ HandleY newtype CollectionZ = CollectionZ CollectionY instance Collection CollectionZ HandleZ where getHandle (CollectionZ collectionY) = map HandleZ $ getHandles collectionY -- Error: `getHandle' is not a (visible) method of class `Collection' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 04:45:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 04:45:16 -0000 Subject: [GHC] #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) In-Reply-To: <047.9478e62bd80e36e2a95f7745037003bc@haskell.org> References: <047.9478e62bd80e36e2a95f7745037003bc@haskell.org> Message-ID: <062.12b9f640d400435c8dfce5acf89cb0cf@haskell.org> #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) -------------------------------------+------------------------------------- Reporter: takenobu | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13126 #9224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by takenobu): I am planning to submit a patch. This is the patch of the current version:\\ https://github.com/takenobu-hs/ghc/compare/master...takenobu-hs:wip /numeric-underscores About it, Iavor gave me good advice:\\ https://github.com/ghc-proposals/ghc- proposals/pull/76#issuecomment-344347463 That is, I unify the definition of Lexer and add a validation function. After investigating how to implement the function for validation, I will submit the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 04:47:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 04:47:35 -0000 Subject: [GHC] #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) In-Reply-To: <047.9478e62bd80e36e2a95f7745037003bc@haskell.org> References: <047.9478e62bd80e36e2a95f7745037003bc@haskell.org> Message-ID: <062.09288ecf1ab1d66470c26da9fbaf2353@haskell.org> #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) -------------------------------------+------------------------------------- Reporter: takenobu | Owner: takenobu Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13126 #9224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by takenobu): * owner: (none) => takenobu -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 06:48:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 06:48:09 -0000 Subject: [GHC] #14483: getExecutablePath from System.Environment in base should follow symlinks properly. In-Reply-To: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> References: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> Message-ID: <062.8b2434f6ca641acba0048f1f8ee96926@haskell.org> #14483: getExecutablePath from System.Environment in base should follow symlinks properly. -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.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 angerman): Just to elaborate what is to be done here: 1. Look at `getBaseDir :: IO (Maybe String)` in `compiler/main/SysTools.hs`, and integrate the symbolic link resolution logic from there in `getExecutablePath` in the `System.Environment` Module from the `base` package. 2. If the `MIN_VERSION_base(...)` is high enough, use `getExecutablePath` also on Windows in `compiler/main/SysTools.hs`, `utils/ghc-pkg/Main.hs` and `utils/hsc2hs/Main.hs`. It looks like this should be rather easy, but requires someone with some windows exposure. Testcases in the testsuite for `getExecutablePath` would be a great bonus! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 08:43:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 08:43:27 -0000 Subject: [GHC] #14481: Mutually dependent modules with orphan instances causes missing symbols with single-shot compilation In-Reply-To: <046.537d69b8076d6f4e322b5c70e81602cf@haskell.org> References: <046.537d69b8076d6f4e322b5c70e81602cf@haskell.org> Message-ID: <061.c4c1de8527dacda9ef9cd82dde60564a@haskell.org> #14481: Mutually dependent modules with orphan instances causes missing symbols with single-shot compilation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Thanks for this analysis. Based on it, I added some dummy types to the original problem files and it now links. So there is a short term workaround at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 12:43:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 12:43:54 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.b70138fc4e319aa5d3e8c2489b8b8bcd@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: phyx- (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 12:53:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 12:53:00 -0000 Subject: [GHC] #14460: Can't decompose ghc.exe path In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.50a9a840f5756c3befcca01e2d66871f@haskell.org> #14460: Can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | 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 Phyx-): * cc: Phyx- (added) Comment: You can right click on the drive and choose properties. It should tell you what file system it is. I have never tried this from a network drive. Most likely we're getting an access denied when trying to resolve the path on the network drive. It could also be network instability as Smb can be unstable when doing file attribute checks. I'll see if I can't special case network mounts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 16:03:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 16:03:55 -0000 Subject: [GHC] #14484: GHC rejects use of mulit-param type class. In-Reply-To: <048.7b80256ede65b84a84caa9f7d57a06cc@haskell.org> References: <048.7b80256ede65b84a84caa9f7d57a06cc@haskell.org> Message-ID: <063.ba8c2e0a6180cee22bb1d36e1a4fd263@haskell.org> #14484: GHC rejects use of mulit-param type class. -------------------------------------+------------------------------------- Reporter: trinithis | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Well, yes. This is to be expected—in the last `Collection` instance, you mispelled `getHandles` as `getHandle` in: {{{#!hs getHandle (CollectionZ collectionY) = ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 18:18:57 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 18:18:57 -0000 Subject: [GHC] #14336: ghci leaks memory In-Reply-To: <051.dbf33557716163bb981beab6790198d1@haskell.org> References: <051.dbf33557716163bb981beab6790198d1@haskell.org> Message-ID: <066.ece922ad5ffbdff75eb8e3a29460ba9c@haskell.org> #14336: ghci leaks memory -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by alanz): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 18:24:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 18:24:21 -0000 Subject: [GHC] #14336: ghci leaks memory In-Reply-To: <051.dbf33557716163bb981beab6790198d1@haskell.org> References: <051.dbf33557716163bb981beab6790198d1@haskell.org> Message-ID: <066.df116e687f3d69134db0439ba7f91779@haskell.org> #14336: ghci leaks memory -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by saurabhnanda): * cc: saurabhnanda (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 18:26:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 18:26:36 -0000 Subject: [GHC] #14336: ghci leaks memory In-Reply-To: <051.dbf33557716163bb981beab6790198d1@haskell.org> References: <051.dbf33557716163bb981beab6790198d1@haskell.org> Message-ID: <066.55da03681c02efda93f4746cef8be754@haskell.org> #14336: ghci leaks memory -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by saurabhnanda): I can confirm that this occurs in GHCi, Intero, and HIE on Mac OSX. Someone suggested `:set +r` could solve this, but it doesn't seem to help. However, `:set -fobject-code` *seems* to either slow-down the memory leak or stop it altogether. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 19:39:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 19:39:55 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.4cd83ef3f716f5497fb34dfab8814dc8@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.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 bgamari): Thanks DanielG, this is quite helpful. If I compile with profiling enabled the profile claims that heap size increases to around 100 MB and then immediately decreases back to essentially zero. The GC statistics reported are in line with comment:10: {{{ $ ./LeakyResetStringTable2 +RTS -p -T -hy gcdetails_live (MB): 0.9342498779296875 gcdetails_mem_in_use (MB): 82.0 VmData (MB): 235.83984375 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 19:44:50 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 19:44:50 -0000 Subject: [GHC] #14485: Typo in blog post. Message-ID: <045.139435f6984ca4dc271d75d35c0e6487@haskell.org> #14485: Typo in blog post. -------------------------------------+------------------------------------- Reporter: bmusin | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.2.1 Keywords: typo | 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://ghc.haskell.org/trac/ghc/blog/ghc-8.2.11-released Should be "developers", not "develpoers" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 20:02:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 20:02:20 -0000 Subject: [GHC] #11392: Decide and document how semicolons are supposed to work in GHCi In-Reply-To: <046.d75fcf3d7505bd227ba71ab98306e831@haskell.org> References: <046.d75fcf3d7505bd227ba71ab98306e831@haskell.org> Message-ID: <061.d1dc508d508e65a944e3c31dc55c7383@haskell.org> #11392: Decide and document how semicolons are supposed to work in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 7.10.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10663, #7625 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I also have no idea when this was fixed but indeed it appears it was. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 20:04:42 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 20:04:42 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.74b105e26e10ddbfbadc679fc07b7927@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Very interesting. This looks great; thanks chris_r_timmons! I suppose given that the script needs to be run on a built tree it would be easiest to just run this at the end of `validate`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 20:07:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 20:07:31 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.c2482a8df65f8d26161ded44bcb8e8b3@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 21:09:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 21:09:17 -0000 Subject: [GHC] #14372: CMM contains a bunch of tail-merging opportunities In-Reply-To: <048.1c543d9c1482e4763ed7a0bf48a66309@haskell.org> References: <048.1c543d9c1482e4763ed7a0bf48a66309@haskell.org> Message-ID: <063.090b4a4857733ec5e549eae3cd549e88@haskell.org> #14372: CMM contains a bunch of tail-merging opportunities -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 nomeata): “This” is ambiguous. The original ticket asks for commoning up “almost equal” locks (by introducing a lookup table). I believe @jp.rider63 refers to that. Later in the discussion, global CBE was brought up, which @heisenbug seems to be working on. I recommend to open a new ticket for global CBE. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 22:34:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 22:34:38 -0000 Subject: [GHC] #14483: getExecutablePath from System.Environment in base should follow symlinks properly. In-Reply-To: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> References: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> Message-ID: <062.f30901bb99c245f257ef63494526e0fc@haskell.org> #14483: getExecutablePath from System.Environment in base should follow symlinks properly. -------------------------------------+------------------------------------- Reporter: angerman | Owner: alpmestan Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by alpmestan): * owner: (none) => alpmestan Comment: I'll give this a shot early next week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 18 22:54:34 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Nov 2017 22:54:34 -0000 Subject: [GHC] #14460: Can't decompose ghc.exe path In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.cdf26f51467e2d07b0959d497e03379b@haskell.org> #14460: Can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | 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 astert): It's a network drive, and the file system is NTFS. I've run python and cygwin compilers from this drive, so this is odd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 19 13:56:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Nov 2017 13:56:03 -0000 Subject: [GHC] #9118: Can't eta-reduce representational coercions In-Reply-To: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> References: <047.51e26113c799743ba87b936ff219c6a7@haskell.org> Message-ID: <062.6fa40819f668a236921c54f53a33aedb@haskell.org> #9118: Can't eta-reduce representational coercions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9117 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 19 15:36:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Nov 2017 15:36:29 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.bb5508d262a82ff821054afe6f6f0721@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.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 Bodigrim): I am interested in this issue due to #14465. I tried to prepare a patch Phab:D4212, but stumbled upon a build issue. Can someone please explain what went wrong? Sorry, I am new to GHC build system. {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -this-unit-id base-4.11.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base /dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist- install/build/./autogen/cabal_macros.h -package-id rts -package-id ghc- prim-0.5.2.0 -package-id integer-gmp-1.0.1.0 -this-unit-id base -XHaskell2010 -O -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -dynamic-too -c libraries/base/./GHC/Natural.hs -o libraries/base/dist- install/build/GHC/Natural.o -dyno libraries/base/dist- install/build/GHC/Natural.dyn_o :1:1: error: Bad interface file: libraries/base/dist-install/build/GHC/Natural.hi libraries/base/dist-install/build/GHC/Natural.hi: openBinaryFile: does not exist (No such file or directory) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 19 16:13:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Nov 2017 16:13:07 -0000 Subject: [GHC] #6084: Add stg_ap_pnnv and related call patterns In-Reply-To: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> References: <049.725af368c945c55559bda8b9bf6a9e31@haskell.org> Message-ID: <064.5856db8cfcac91fe93f1937f27d5fbe1@haskell.org> #6084: Add stg_ap_pnnv and related call patterns -------------------------------------+------------------------------------- Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8313 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 19 17:54:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Nov 2017 17:54:06 -0000 Subject: [GHC] #14486: Something is fishy in RTS's "max pause" GC statistic Message-ID: <046.08d663b1dbd5b18a47f1951d8af4db59@haskell.org> #14486: Something is fishy in RTS's "max pause" GC statistic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1 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: -------------------------------------+------------------------------------- While looking into a GC issue, I found a peculiar inconsistency between the `+RTS -s` output and that from the eventlog. The `-s` output is, {{{ 13,756,939,024 bytes allocated in the heap 6,085,406,120 bytes copied during GC 182,001,080 bytes maximum residency (22 sample(s)) 753,160 bytes maximum slop 508 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 28674 colls, 28674 par 5.268s 2.949s 0.0001s 0.1016s Gen 1 22 colls, 21 par 0.004s 0.002s 0.0001s 0.0005s Parallel GC work balance: 79.36% (serial 0%, perfect 100%) TASKS: 9 (1 bound, 8 peak workers (8 total), using -N2) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.007s ( 0.017s elapsed) MUT time 4.353s ( 2.556s elapsed) GC time 5.272s ( 2.951s elapsed) EXIT time 0.004s ( 0.072s elapsed) Total time 9.635s ( 5.596s elapsed) Alloc rate 3,160,479,659 bytes per MUT second Productivity 45.2% of total user, 47.0% of total elapsed }}} Note the "Max pause" statistic: gen0 apparently pauses for four orders of magnitude more than gen1. This seems rather hard to believe. Moreover, if I open the eventlog from the same run in threadscope, I find, ||= Generation =||= Collections =||= Par collections =||= Elapsed time =||= Avg pause =||= Max pause =|| || GC Total || 27215 || 25518 || 2.83s || 0.0001s || 0.1016s || || Gen 0 || 25504 || 25504 || 1.55s || 0.0001s || 0.0012s || || Gen 1 || 15 || 14 || 0.99s || 0.0657s || 0.1016s || Hmmmmmmmmm... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 19 19:04:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Nov 2017 19:04:31 -0000 Subject: [GHC] #14486: Something is fishy in RTS's "max pause" GC statistic In-Reply-To: <046.08d663b1dbd5b18a47f1951d8af4db59@haskell.org> References: <046.08d663b1dbd5b18a47f1951d8af4db59@haskell.org> Message-ID: <061.c42909985fe01ee2d3a588af266277ce@haskell.org> #14486: Something is fishy in RTS's "max pause" GC statistic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.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 bgamari): Ahh, I think this may actually be another manifestation of #14445 and therefore fixed by d9f0c24dd01b2f2a9a5ccc2fc45e93064d4ba0c1. Confirming now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 19 21:03:07 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Nov 2017 21:03:07 -0000 Subject: [GHC] #14487: Can't Hide Field When DuplicateRecordFields Is Enabled Message-ID: <052.55fcb5f24afe31abafd77e2adcf88ad5@haskell.org> #14487: Can't Hide Field When DuplicateRecordFields Is Enabled -------------------------------------+------------------------------------- Reporter: iansullivan88 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux DuplicateRecordFields | Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A.hs fails to compile when DuplicateRecordFields is enabled in B.hs. A.hs {{{#!hs module A where import B hiding (duplicateName) test = X duplicateName duplicateName = 5 }}} B.hs {{{#!hs {-# LANGUAGE DuplicateRecordFields #-} module B where data X = X { duplicateName :: Int } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 19 21:33:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Nov 2017 21:33:56 -0000 Subject: [GHC] #14486: Something is fishy in RTS's "max pause" GC statistic In-Reply-To: <046.08d663b1dbd5b18a47f1951d8af4db59@haskell.org> References: <046.08d663b1dbd5b18a47f1951d8af4db59@haskell.org> Message-ID: <061.5bfd381cfa00441a68d31d4b92e9bf35@haskell.org> #14486: Something is fishy in RTS's "max pause" GC statistic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: duog (added) * status: new => closed * resolution: => fixed * milestone: => 8.4.1 Comment: Indeed it's fixed in HEAD. Good work, duog! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 05:42:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 05:42:12 -0000 Subject: [GHC] #14488: Can't define a lens for a field with a constraint Message-ID: <048.86e8973d2180c36f750acacdcb0d1f12@haskell.org> #14488: Can't define a lens for a field with a constraint -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE RankNTypes #-} type Lens' s a = forall f. Functor f => (a -> f a) -> s -> f s data T a = MkT { _tfield :: Eq a => a } tfield :: Eq a => Lens' (T a) a tfield f t = MkT <$> f (_tfield t) }}} This code compiles with GHC 8.2.1. On GHC 8.0.2 the following error is reported: {{{#!hs tfield.hs:8:22: error: • Couldn't match type ‘a’ with ‘Eq a => a’ ‘a’ is a rigid type variable bound by the type signature for: tfield :: forall a. Eq a => Lens' (T a) a at tfield.hs:7:11 Expected type: f (Eq a => a) Actual type: f a • In the second argument of ‘(<$>)’, namely ‘f (_tfield t)’ In the expression: MkT <$> f (_tfield t) In an equation for ‘tfield’: tfield f t = MkT <$> f (_tfield t) • Relevant bindings include t :: T a (bound at tfield.hs:8:10) f :: a -> f a (bound at tfield.hs:8:8) tfield :: Lens' (T a) a (bound at tfield.hs:8:1) }}} I could not find a relevant GHC ticket. Unless it's a known issue, I am going to create a Phab Diff with this code as a test case to avoid a regression in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 06:33:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 06:33:29 -0000 Subject: [GHC] #14489: GHC panic from emacs haskell mode Message-ID: <045.52d72c148fa77cfd2bf5f030568a662d@haskell.org> #14489: GHC panic from emacs haskell mode -------------------------------------+------------------------------------- Reporter: ggoetz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Hello, I encountered a ghc panic while going through one of the chapters from "Haskell Programming from first principles". The following error message is reported from flycheck checker from src/Main.hs in the attached files: {{{ Suspicious state from syntax checker haskell-stack-ghc: Flycheck checker haskell-stack-ghc returned non-zero exit code 1, but its output contained no errors: [1 of 2] Compiling Morse ( [some path]/haskell_programming/ch14/morse/src/Morse.hs, /var/folders/2s/c4mvtf0x5_b4d9gf18r65wwh0000gn/T/flycheck-haskell-ghc- cache90097PyL/Morse.o ) [2 of 2] Compiling Main ( /var/folders/2s/c4mvtf0x5_b4d9gf18r65wwh0000gn/T/flycheck90097c8R/Main.hs, /var/folders/2s/c4mvtf0x5_b4d9gf18r65wwh0000gn/T/flycheck-haskell-ghc- cache90097PyL/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] convertLine_a2Ml :: t_a2Mk[tau:1] (CHoleCan: convertLine)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Try installing a more recent version of haskell-stack-ghc, and please open a bug report if the issue persists in the latest release. Thanks! }}} Stack upgrade reports "Skipping binary upgrade, you are already running the most recent version". I'm not entirely sure whether this should be reported or not (I can't say I know what I'm doing...), so I'm reporting it just in case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 06:34:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 06:34:28 -0000 Subject: [GHC] #14489: GHC panic from emacs haskell mode In-Reply-To: <045.52d72c148fa77cfd2bf5f030568a662d@haskell.org> References: <045.52d72c148fa77cfd2bf5f030568a662d@haskell.org> Message-ID: <060.acd989f83eb5b8f2f56ebdb74ea26ea8@haskell.org> #14489: GHC panic from emacs haskell mode -------------------------------------+------------------------------------- Reporter: ggoetz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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 ggoetz): * Attachment "morse_bak.zip" added. On my machine, opening Main.hs from emacs with haskell-mode enabled causes the issue -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 07:15:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 07:15:59 -0000 Subject: [GHC] #14460: Symlink resolving fails against SMB mounts (was: Can't decompose ghc.exe path) In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.039dc090a805ad8cc7693a5aefb0e9a9@haskell.org> #14460: Symlink resolving fails against SMB mounts -------------------------------------+------------------------------------- Reporter: astert | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | 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 Phyx-): * owner: (none) => Phyx- * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 08:25:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 08:25:41 -0000 Subject: [GHC] #14490: TTG Snags Message-ID: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14482 Differential Rev(s): | Wiki Page: | ImplementingTreesThatGrow -------------------------------------+------------------------------------- == Context ImplementingTreesThatGrow The intention is to get the first-pass implementation of Trees that Grow into GHC 8.4.1. So far the following commits are on master - https://phabricator.haskell.org/rGHC438dd1cbba13d35f3452b4dcef3f94ce9a216905 - https://phabricator.haskell.org/rGHCe3ec2e7ae94524ebd111963faf34b84d942265b4 - https://phabricator.haskell.org/rGHC47ad6578ea460999b53eb4293c3a3b3017a56d65 Unfortunately we have picked up compile-time performance regressions in compiling GHC itself, with these patches. The perf.haskell.org results are - https://perf.haskell.org/ghc/#revision/438dd1cbba13d35f3452b4dcef3f94ce9a216905 - https://perf.haskell.org/ghc/#revision/e3ec2e7ae94524ebd111963faf34b84d942265b4 - https://perf.haskell.org/ghc/#revision/47ad6578ea460999b53eb4293c3a3b3017a56d65 Summary: each of the three patches caused GHC validate time to worsen by another 5% or so, cumulatively pushing compile time from 2011 to 2400 seconds. It seems the major culprit is deriving the `Data` instances, probably related to the complex constraint sets required to ensure that all the extension points have `Data` instances too. Some discussion around this is captured in ImplementingTreesThatGrow/Instances == Things tried so far PLAN E (ImplementingTreesThatGrow/Instances#PLANE), in https://github.com/ghc/ghc/tree/wip/ttg5-data-one-file-2017-11-17. This puts all the `Data` derivations for the hsSyn AST into a single file, `hsSyn/HsInstances.hs`. This causes compile-time memory usage to spike up to around 7GB when compiling this file. Gipedia reports a compilation time of 2468 secs for this version, which perhaps indicates that the instance derivation is not the main culprit. The module itself only takes in the order of 45secs to compile, on `home .smart-cactus.org` (http://lpaste.net/7779809210564345856) Splitting the `HsInstances.hs` file in 2, as per https://github.com/ghc/ghc/tree/wip/ttg5-data-2017-11-17 reduces the memory requirement for each, but shows up #14482, where there is a linker failure due to incorrectly processing boot files. == Next Steps I guess the first thing to do is to try to isolate what precisely is causing the slowdown. It may not be instance generation at all. Also, it is probably better to revert the three patches from master, when cutting the 8.4 initial freeze. Open to suggestions ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 11:10:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 11:10:14 -0000 Subject: [GHC] #14336: ghci leaks memory In-Reply-To: <051.dbf33557716163bb981beab6790198d1@haskell.org> References: <051.dbf33557716163bb981beab6790198d1@haskell.org> Message-ID: <066.5d70d1668366f395212dcd9ba99fd89a@haskell.org> #14336: ghci leaks memory -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | 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: | -------------------------------------+------------------------------------- Changes (by mnislaih): * cc: mnislaih (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 11:20:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 11:20:46 -0000 Subject: [GHC] #14491: Windows build with "--enable-distro-toolchain" fails with "make install" Message-ID: <049.c969c3b9ee81b4bcc4dcdf0f7b8ec68f@haskell.org> #14491: Windows build with "--enable-distro-toolchain" fails with "make install" -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: make | Operating System: Windows Architecture: x86_64 | Type of failure: Installing GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: 13792 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm building ghc (commit 606bbc310654fcf56fe068905bb1aca30d2f0a8a) under mingw64 shell. I ran the configure script with "--enable-distro- toolchain", and "make -j4" succeeds, yet "make install" yields the following error: {{{ ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for 'phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final install /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin" "rm" -f "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghcii.sh" echo "#!/bin/sh" >> /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghcii.sh echo 'exec "$(dirname "$0")"/ghc --interactive "$@"' >> /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghcii.sh chmod +x /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghcii.sh cp /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghcii.sh /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghcii-8.3.20171120.sh chmod +x /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghcii-8.3.20171120.sh /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include" /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/." && /usr/bin/install -c -m 644 includes/./*.h "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/./" && /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/rts" && /usr/bin/install -c -m 644 includes/rts/*.h "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/rts/" && /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/rts/prof" && /usr/bin/install -c -m 644 includes/rts/prof/*.h "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/rts/prof/" && /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/rts/storage" && /usr/bin/install -c -m 644 includes/rts/storage/*.h "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/rts/storage/" && /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/stg" && /usr/bin/install -c -m 644 includes/stg/*.h "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/stg/" && true /usr/bin/install -c -m 644 includes/ghcautoconf.h includes/ghcplatform.h includes/ghcversion.h includes/dist- derivedconstants/header/DerivedConstants.h "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/" /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include" /usr/bin/install -c -m 644 rts/dist/build/ffi.h rts/dist/build/ffitarget.h "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib/include/" /usr/bin/install -c -m 644 utils/hsc2hs/template-hsc.h "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/lib" "cp" driver/ghci/dist/build/tmp/ghci.exe driver/ghci/dist/build/tmp/ghci-8.3.20171120.exe /usr/bin/install -c -m 755 -d "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin" for i in utils/hp2ps/dist-install/build/tmp/hp2ps.exe driver/ghci/dist/build/tmp/ghci.exe driver/ghci/dist/build/tmp/ghci-8.3.20171120.exe driver/ghc/dist/build/tmp/ghc-8.3.20171120.exe driver/haddock/dist/build/tmp/haddock-8.3.20171120.exe utils/hsc2hs/dist- install/build/tmp/hsc2hs.exe utils/ghc-pkg/dist-install/build/tmp/ghc- pkg.exe utils/hpc/dist-install/build/tmp/hpc.exe utils/runghc/dist- install/build/tmp/runghc.exe ghc/stage2/build/tmp/ghc-stage2.exe; do \ /usr/bin/install -c -m 755 $i "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin" ; \ done "cp" /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/runghc.exe /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/runhaskell.exe "rm" -f "/C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghc.exe" "mv" -f /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin /ghc-stage2.exe /C/Users/astro/AppData/Local/Programs/stack/x86_64-windows/ghc-8.3.20171120/bin/ghc.exe make[1]: *** No rule to make target 'inplace/mingw', needed by 'install_mingw'. Stop. make: *** [Makefile:127: install] Error 2 }}} Is this a bug related to "--enable-distro-toolchain"? "inplace/mingw" rule should not exist here in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 11:21:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 11:21:17 -0000 Subject: [GHC] #14491: Windows build with "--enable-distro-toolchain" fails with "make install" In-Reply-To: <049.c969c3b9ee81b4bcc4dcdf0f7b8ec68f@haskell.org> References: <049.c969c3b9ee81b4bcc4dcdf0f7b8ec68f@haskell.org> Message-ID: <064.06e00e0a9a3eb5b8cafeead0597123f1@haskell.org> #14491: Windows build with "--enable-distro-toolchain" fails with "make install" -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: make Operating System: Windows | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #13792 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by terrorjack): * related: 13792 => #13792 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 12:48:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 12:48:49 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.a30b7feb8872f37ddd31b992207dc1a4@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by Shayan-Najd): > Splitting the HsInstances.hs file in 2, as per ​ > https://github.com/ghc/ghc/tree/wip/ttg5-data-2017-11-17 reduces the memory requirement > for each, but shows up #14482, where there is a linker failure due to incorrectly > processing boot files. It seems that #14482 is fixed. If yes, then what's the compile-time of GHC itself in this branch? > It may not be instance generation at all. Can we somehow time the constraint solver, before and after the patches? Can we try Plan B and time it? (That is: instead of one Data instance for the HsSyn traversals, make three.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 13:03:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 13:03:48 -0000 Subject: [GHC] #14491: Windows build with "--enable-distro-toolchain" fails with "make install" In-Reply-To: <049.c969c3b9ee81b4bcc4dcdf0f7b8ec68f@haskell.org> References: <049.c969c3b9ee81b4bcc4dcdf0f7b8ec68f@haskell.org> Message-ID: <064.7207337a439ce1328612315692045cff@haskell.org> #14491: Windows build with "--enable-distro-toolchain" fails with "make install" -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: make Operating System: Windows | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #13792 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * type: bug => feature request Comment: `--enable-distro-toolchain` was created to aid in the testing of new GCC versions and packaging of `msys2` versions of the compiler, which wouldn't use our install script anyway as it uses `makepkg`. So I don't think this is a bug, but a feature as you want to use it for something it wasn't intended to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 13:14:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 13:14:38 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory Message-ID: <044.e21e37476590d999c81ca942af908658@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System | Keywords: memory ulimit | Operating System: Linux Architecture: x86_64 | Type of failure: Poor/confusing (amd64) | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This was first noticed when running a binary produced with GHC 8.0.2 through a queueing system (Sun Grid Engine) that limits available memory by setting `ulimit -v`. When running with **unlimited** address space, the binary reserves 1TB of RAM and everything works as expected. When running with **limited** address space, reservation happens in powers of 2 leading to significant unused memory at higher memory values. The tests are summarized in the following table: {{{ Limit VIRT Unused (all in GB) 8 4 8 10 8 2 16 8 8 32 16 16 34 32 2 64 32 32 66 64 2 128 64 64 130 128 2 256 128 128 258 256 2 512 256 256 514 512 2 1024 512 512 }}} In the last line, setting `ulimit -v` to 1024GB (1073741824) causes the binary to only be able to reserve 512GB. If at runtime the software needs more than 512GB it will abort with "out of memory" instead of expanding to as close to the specified ulimit as possible. PS: Is there any way to make the "out of memory" error a little bit more informative? Something that informs the user of how much memory was already being used and how much more was going to be reserved when the failure was seen? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 13:16:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 13:16:20 -0000 Subject: [GHC] #14489: GHC panic from emacs haskell mode In-Reply-To: <045.52d72c148fa77cfd2bf5f030568a662d@haskell.org> References: <045.52d72c148fa77cfd2bf5f030568a662d@haskell.org> Message-ID: <060.59008a1a009a3c7ce405d209d12a0b24@haskell.org> #14489: GHC panic from emacs haskell mode -------------------------------------+------------------------------------- Reporter: ggoetz | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #13106 * milestone: => 8.2.1 Comment: Thanks for submitting this! This is very likely another manifestation of #13106, which is fixed in 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 13:20:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 13:20:05 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.3494851ecf54f5eba820610a227e2d0d@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by simonpj): I think you are referring to Plan B on [wiki:ImplementingTreesThatGrow/Instances]. Why not do Plan C? It generates one third of the amount of code and is really simple. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 13:25:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 13:25:12 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.d46b838473a30e261b234dea21995e96@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): I agree on Plan C. But I am currently concerned that the major slowdown is not just from the instances. I understand bgamari is going to revert the TTG commits, and there is now a detailed timing flag (https://phabricator.haskell.org/rGHC2da7813b771edcb3efb1b067b986d10f5de4beaf) which we will be able to use to compare the compilation time for the before and after versions. This should at least give us an idea of where the major impacts are coming from, in terms of modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 13:27:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 13:27:02 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.a8c11504697dbd7b2ef02e5e0cbf67ed@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by Shayan-Najd): Yes, [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances#PLANB Plan B]. I only suggest Plan B to reduce the constraint sets by specialising them. If it doesn't affect the performance, I agree that the alternatives with less code is preferred. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 13:27:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 13:27:55 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.7cb8142299a5e6301d01ed8a96f8ac23@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by bgamari): I'd like to point out that I introduced `-ddump-timings` last week specifically to help in benchmarking liking that suggested by Shayan in comment:1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 13:30:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 13:30:30 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.b97488f41b596c91538a181ab5e37063@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by simonpj): OK. Sounds as if we are agreed on Plan C unless we discover a reason not to follow it. Of course that may or may not solve our problem. But it simplifies solving whatever remaining problem we have. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 13:35:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 13:35:39 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.f7bebfeafc8a733b705ed29aa26f73b4@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): And it probably makes sense to do it in the context of the `HsInstances.hs` file, as then it groups all the instances together. Or should they happen in the original locations? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 13:39:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 13:39:42 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.571d3a047a278214884acbe93bff5033@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): The other concern is the 8.4 freeze. We don't actually have any idea how long it is going to take to sort this out. I know Ben is concerned about having to cherry-pick across TTG if it lands in the next month or two, while 8.4 is still settling down. So, do we revert, and investigate on a long-lived branch, or carry on investigating? Or revert and investigate offline, but hold off the 8.4 freeze? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 13:42:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 13:42:51 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.55bb598c69b7695608cafb319d556946@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by Shayan-Najd): I am not sure about the impact of grouping on the compile-time of GHC itself. But, I believe we eventually want to group `Data` (and others like `Outputable`) instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 13:46:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 13:46:56 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.4de8c87f7d439606e9d5b3db8465dd9a@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by simonpj): For 8.4, it's up to Ben our release manager, and (if he needs to consult) our devops group. It would not be terrible to leave it out of 8.4; because 8.6 will be along in six months. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 14:01:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 14:01:32 -0000 Subject: [GHC] #14482: GHC -M mode fails to ensure that boot files are built before source files In-Reply-To: <046.f887b8665019281d6519a59f53c32782@haskell.org> References: <046.f887b8665019281d6519a59f53c32782@haskell.org> Message-ID: <061.1d10fccfa51e5a28a77fb7bc21a09e64@haskell.org> #14482: GHC -M mode fails to ensure that boot files are built before source files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14481 | Differential Rev(s): Phab:D4208 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think the payload of the patch is: * Make `M.o` depend on `M.hi-boot`. But let me ask this: in what program will that that not happen without this patch? I think only on programs where * Neither `M.hs` nor any of the module that `M.hs` imports, transitively, does a `{-# SOURCE #-}` import of `M`. And in those cases we can just get rid of `M.hs-boot` entirely. It's not needed. I've had a look at the example in #14481. (I'm not sure why this ticket is distinct from #14481, incidentally.) I believe it has the same property: no one imports `Instances1` in fact. I grant that GHC should not crash. But rather than simply adding an extra dependency, if we find that if there is no transitive edge from `M.hs` to `M.hs-boot`, we should a) add one b) emit a warning that `M.hs-boot` is apparently redundant. Failing to do (b) seems wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 14:11:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 14:11:31 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.7999ee2b44fedbcf16cb4819b794eb6a@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.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 bgamari): Have you tried cleaning your tree? It looks like the build system neglected to build that interface file (which is a bit perplexing, but stranger things have happened with the `make` build system). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 15:12:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 15:12:09 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory In-Reply-To: <044.e21e37476590d999c81ca942af908658@haskell.org> References: <044.e21e37476590d999c81ca942af908658@haskell.org> Message-ID: <059.420a028c641db38a6f2284bdda90ec18@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: memory ulimit Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I suppose we could set an upper bound on the reservation size. That is, exponentially increase up to, e.g., 32GB and then from there allocate 32 GB at a time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 15:12:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 15:12:51 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory In-Reply-To: <044.e21e37476590d999c81ca942af908658@haskell.org> References: <044.e21e37476590d999c81ca942af908658@haskell.org> Message-ID: <059.598e685c83d4fdbe253623631b5976fd@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: memory ulimit Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > PS: Is there any way to make the "out of memory" error a little bit more informative? Something that informs the user of how much memory was already being used and how much more was going to be reserved when the failure was seen? Probably; unfortunately there are a number of places where this error is thrown scattered about the runtime. This should also be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 15:30:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 15:30:43 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.285e360034e095b36d1b50d93fb671fe@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): I am getting {{{#!hs instance Data (XOverLit (GhcPass p)) where ---- compiler/hsSyn/HsLit.hs:143:10: error: • Illegal type synonym family application in instance: XOverLit (GhcPass p) • In the instance declaration for ‘Data (XOverLit (GhcPass p))’ | 143 | instance Data (XOverLit (GhcPass p)) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Am I missing something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 15:46:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 15:46:29 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory In-Reply-To: <044.e21e37476590d999c81ca942af908658@haskell.org> References: <044.e21e37476590d999c81ca942af908658@haskell.org> Message-ID: <059.2edbb6f5409191f5bd317a65d2968553@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: memory ulimit Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by unode): Replying to [comment:1 bgamari]: > I suppose we could set an upper bound on the reservation size. That is, exponentially increase up to, e.g., 32GB and then from there allocate 32 GB at a time. 32GB might still be quite large of a slice. On a 64GB machine that would be half of the total, making the software use at most ~32GB (since 64GB wouldn't be reservable). I don't know anything about GHC's internals so take this with a grain of salt. Would it make sense to instead half the previous reservation and keep halfing if unsuccessful? Otherwise, on systems that rely on this `ulimit -v` behavior, there will always be a gap between possible memory and what the software is actually able to use. My current understanding is that a process tries to reserve memory and doesn't try to change this value during runtime. Is it correct to say that any effort (or lack thereof) at start will constrain execution? If so shouldn't a "reserve as much as the system allows" effort be the default? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 16:08:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 16:08:41 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.61e3e82f80c622206051f60675ed3d18@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 tdammers): Progress made so far: - Reduced algorithmic complexity in register spilling ([comment:33]) - Minor improvements in the pretty-based code writer ([comment:34]) - Refactored generated `Read` code (comment [comment:37] / ticket [ticket:14364]) - Observed that `Read` instances generate long chains of monadic binds over a monad that introduces nested closures when binding (`ReadP`, specifically); and that deeply nested closures in general cause the register allocator to repeatedly unpack and re-pack free variables, which leads to quadratic behavior. The fix for this has been split off into [ticket:14461]. Things left to do: - Replace `pretty` with something that doesn't share its nonlinearities ([ticket:14005]) - Once [ticket:14461] is done, it may be worth digging further; right now, the nested-closures nonlinearity makes it difficult to isolate other bottlenecks though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 16:14:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 16:14:56 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.62b7df143ade6cc3d3f856d7c09a226f@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 simonpj): Great summary, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 16:33:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 16:33:08 -0000 Subject: [GHC] #11721: GADT-syntax data constructors don't work well with TypeApplications In-Reply-To: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> References: <047.d3cda57aa918919c3cdf02eb21c0a581@haskell.org> Message-ID: <062.2c184a4fec0b5c1ee413613db68f6b37@haskell.org> #11721: GADT-syntax data constructors don't work well with TypeApplications -------------------------------------+------------------------------------- Reporter: goldfire | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T11721, th/T11721_TH, | typecheck/should_compile/T13848 Blocked By: | Blocking: Related Tickets: #13848, #12025 | Differential Rev(s): Phab:D3687, Wiki Page: | Phab:D4070 -------------------------------------+------------------------------------- Comment (by dfeuer): Aha. Simon, this was the problem I mentioned on today's call. The documentation wasn't updated to reflect the fix until fairly recently, and I didn't notice. Sorry for the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 16:34:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 16:34:39 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.118b9f39ceb21fdd6ae7966a18e91a37@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 AndreasK): * cc: AndreasK (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 16:51:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 16:51:02 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.21f44e8300c254fda843f3503789af39@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by Shayan-Najd): A quick take: I am not sure if you are doing the right thing: typeclass instances for open type families? (I can now see that Plan C also has something similar to this). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 16:54:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 16:54:09 -0000 Subject: [GHC] #14493: Why is g++ necessary to compile GHC? Message-ID: <046.f6ec23ebd8a585358047482b310433b0@haskell.org> #14493: Why is g++ necessary to compile GHC? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Simonpj noted after a system upgrade that GHC failed to build unless `g++` is installed. `libffi`'s `configure` otherwise failed with {{{ configure:13086: checking how to run the C++ preprocessor configure:13113: gcc -E conftest.cpp gcc: error trying to exec 'cc1plus': execvp: No such file or directory }}} Why is this necessary? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 16:54:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 16:54:19 -0000 Subject: [GHC] #14494: TBQueue leaks space under certain workloads Message-ID: <047.f58f0c7c928ab79f4f0451929939d250@haskell.org> #14494: TBQueue leaks space under certain workloads -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.2.1 (other) | Keywords: stm | 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'm using TBQueue and I noticed suspiciously high memory usage, so I decided to profile and it turned out that readTBQueue leaks space (see attached before.png). After closer inspection it turned out it's the `writeTVar rsize (r + 1)` in readTBQueue definition that's the problem - after substitution it for `writeTVar rsize $! r + 1` the leak is gone (see attached after.png) Here are -s outputs: Before: {{{ 366,535,518,024 bytes allocated in the heap 115,643,281,224 bytes copied during GC 241,356,416 bytes maximum residency (1182 sample(s)) 1,516,944 bytes maximum slop 392 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 247273 colls, 247273 par 128.854s 28.654s 0.0001s 0.0182s Gen 1 1182 colls, 1181 par 352.162s 87.812s 0.0743s 0.1322s Parallel GC work balance: 78.17% (serial 0%, perfect 100%) TASKS: 24 (1 bound, 16 peak workers (23 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.003s ( 0.003s elapsed) MUT time 581.754s (226.191s elapsed) GC time 317.130s ( 75.533s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 163.885s ( 40.933s elapsed) EXIT time 0.013s ( 0.011s elapsed) Total time 1062.789s (301.738s elapsed) Alloc rate 630,052,684 bytes per MUT second Productivity 54.7% of total user, 61.4% of total elapsed gc_alloc_block_sync: 8998531 whitehole_spin: 96 gen[0].sync: 180553 gen[1].sync: 31648044 }}} After: {{{ 431,671,260,464 bytes allocated in the heap 86,540,207,400 bytes copied during GC 170,338,336 bytes maximum residency (1381 sample(s)) 1,159,472 bytes maximum slop 260 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 290179 colls, 290179 par 148.921s 33.097s 0.0001s 0.0217s Gen 1 1381 colls, 1380 par 206.679s 51.492s 0.0373s 0.0528s Parallel GC work balance: 75.51% (serial 0%, perfect 100%) TASKS: 23 (1 bound, 17 peak workers (22 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.005s ( 0.004s elapsed) MUT time 681.718s (241.009s elapsed) GC time 258.643s ( 60.370s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 96.957s ( 24.219s elapsed) EXIT time 0.009s ( 0.007s elapsed) Total time 1037.335s (301.390s elapsed) Alloc rate 633,210,748 bytes per MUT second Productivity 65.7% of total user, 71.9% of total elapsed gc_alloc_block_sync: 5494680 whitehole_spin: 184 gen[0].sync: 184109 gen[1].sync: 24223953 }}} Attached patch fixes the problem (I made all Int increments/decrements in the module strict as there is no need for them to be lazy). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 16:55:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 16:55:00 -0000 Subject: [GHC] #14494: TBQueue leaks space under certain workloads In-Reply-To: <047.f58f0c7c928ab79f4f0451929939d250@haskell.org> References: <047.f58f0c7c928ab79f4f0451929939d250@haskell.org> Message-ID: <062.aa2eeb742eac0870d32d15f72ec18eda@haskell.org> #14494: TBQueue leaks space under certain workloads -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.2.1 (other) | Resolution: | Keywords: stm 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 arybczak): * Attachment "before.png" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 16:55:15 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 16:55:15 -0000 Subject: [GHC] #14494: TBQueue leaks space under certain workloads In-Reply-To: <047.f58f0c7c928ab79f4f0451929939d250@haskell.org> References: <047.f58f0c7c928ab79f4f0451929939d250@haskell.org> Message-ID: <062.98c32afb6b8211db199be7820efe5449@haskell.org> #14494: TBQueue leaks space under certain workloads -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.2.1 (other) | Resolution: | Keywords: stm 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 arybczak): * Attachment "after.png" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 16:55:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 16:55:26 -0000 Subject: [GHC] #14493: Why is g++ necessary to compile GHC? In-Reply-To: <046.f6ec23ebd8a585358047482b310433b0@haskell.org> References: <046.f6ec23ebd8a585358047482b310433b0@haskell.org> Message-ID: <061.b49a666df87a3152cff1a0042ec5d64b@haskell.org> #14493: Why is g++ necessary to compile GHC? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 bgamari): * status: new => closed * resolution: => wontfix Comment: Right after I hit "submit" the reason became clear: `libffi` is explicitly looking for a C++ preprocessor. Consequently it uses `.cpp` as the extension for the source file it feeds `gcc`. This compels `gcc` to go looking for a C++ compiler. It looks like we will just need to document the `g++` requirement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 16:57:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 16:57:32 -0000 Subject: [GHC] #14494: TBQueue leaks space under certain workloads In-Reply-To: <047.f58f0c7c928ab79f4f0451929939d250@haskell.org> References: <047.f58f0c7c928ab79f4f0451929939d250@haskell.org> Message-ID: <062.4354dd699245f4d5463c6f7e9b1986be@haskell.org> #14494: TBQueue leaks space under certain workloads -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.2.1 (other) | Resolution: | Keywords: stm 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 arybczak): * Attachment "0001-Fix-space-leak-in-TBQueue-14494.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 17:00:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 17:00:32 -0000 Subject: [GHC] #14494: TBQueue leaks space under certain workloads In-Reply-To: <047.f58f0c7c928ab79f4f0451929939d250@haskell.org> References: <047.f58f0c7c928ab79f4f0451929939d250@haskell.org> Message-ID: <062.5e0f18dea9db0f8bc845aa1e8d85a1bb@haskell.org> #14494: TBQueue leaks space under certain workloads -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: libraries | Version: 8.2.1 (other) | Resolution: | Keywords: stm 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 arybczak): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 17:04:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 17:04:10 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.566b892e1dd6d33722316ed80b9bef1f@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by bgamari): Simonpj mentioned to me that Plans C and D are not feasible; they call for instances of type functions, which cannot be defined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 17:07:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 17:07:19 -0000 Subject: [GHC] #14495: Relocatable GHC Message-ID: <046.eee2e7ee2b5b793946317cc2c012eb42@haskell.org> #14495: Relocatable GHC -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Moritz Angerman has recently been working on [[https://github.com/snowleopard/hadrian/pull/445|enabling]] relocatable builds of GHC in Hadrian. This will enable a user to extract a bindist anywhere in their file system and expect it to work. Moreover, it should simplify our installation procedure -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 17:07:29 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 17:07:29 -0000 Subject: [GHC] #14495: Relocatable GHC In-Reply-To: <046.eee2e7ee2b5b793946317cc2c012eb42@haskell.org> References: <046.eee2e7ee2b5b793946317cc2c012eb42@haskell.org> Message-ID: <061.becd85060b67c69dfeabbd46d5f32458@haskell.org> #14495: Relocatable GHC -------------------------------------+------------------------------------- Reporter: bgamari | Owner: angerman Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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 bgamari): * owner: (none) => angerman -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 17:13:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 17:13:57 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.c8cb45c29be601c0743d24f327f20ff0@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by Shayan-Najd): Then, back to comment 1: can we try Plan B and time it? (That is: instead of one Data instance for the HsSyn traversals, make three.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 17:20:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 17:20:45 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.9e254a3bdde134f9ff0ff8b13bd9a369@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by Shayan-Najd): > Simonpj mentioned to me that Plans C and D are not feasible; they call for instances of > type functions, which cannot be defined. Updated the [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances wiki] accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 17:36:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 17:36:28 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.b8121456ebfa2685d81e416ddd4fe3b6@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm 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 arybczak): Let's revive this ticket and get it resolved. For what it's worth, readTBQueue uses lazy let for reverse and it's even appropriately commented: `NB. lazy: we want the transaction to be short, otherwise it will conflict`. This issue makes me anxious to use TQueue in any real-world scenario because given sufficiently large spike in produced values it leads to memory exhaustion, as at some point the consumer will not be able to finish the transaction without conflicts even if rate of produced values goes down. I'm just going to attach a patch that makes the definition of readTQueue consistent with readTBQueue and we can go from there. If you know what exact benchmarks we need to run, please speak up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 17:36:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 17:36:52 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.6d497e9f015738e12f35f949306c2887@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm 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 arybczak): * Attachment "0001-Make-definition-of-readTQueue-consistent-with- readTB.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 17:37:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 17:37:05 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.99642a65891530eb0af6abd0a1ec574c@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm 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 arybczak): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 18:16:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 18:16:43 -0000 Subject: [GHC] #14488: Can't define a lens for a field with a constraint In-Reply-To: <048.86e8973d2180c36f750acacdcb0d1f12@haskell.org> References: <048.86e8973d2180c36f750acacdcb0d1f12@haskell.org> Message-ID: <063.b50fca2b75129a0776a3e148e7ccd80b@haskell.org> #14488: Can't define a lens for a field with a constraint -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.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 RyanGlScott): It looks like 3f5673f34a2f761423027bf46f64f7499708725f (`A collection of type-inference refactorings.`) fixed this. A regression test would be much appreciated! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 18:48:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 18:48:19 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals In-Reply-To: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> References: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> Message-ID: <062.33d8cd01a361ecdb40557b9cf01afee6@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: 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 AndreasK): * cc: AndreasK (added) * status: closed => new * resolution: fixed => * failure: Compile-time crash => Incorrect result at runtime Comment: In MatchLit [https://ghc.haskell.org/trac/ghc/browser/ghc/compiler/deSugar/MatchLit.hs#L76 dsLit] doesn't use the `mkMachInt` functions resulting in potentially faulty code. `y = I# 0x8000000000000000# :: Int` compiles without warning with -Wall for example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 19:01:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 19:01:57 -0000 Subject: [GHC] #14488: Can't define a lens for a field with a constraint In-Reply-To: <048.86e8973d2180c36f750acacdcb0d1f12@haskell.org> References: <048.86e8973d2180c36f750acacdcb0d1f12@haskell.org> Message-ID: <063.77051caba51d2386cb9c8d062d48d977@haskell.org> #14488: Can't define a lens for a field with a constraint -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.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): Phab:D4213 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * status: new => patch * differential: => Phab:D4213 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 21:03:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 21:03:35 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.99ebf49c47cdf3cd364f16e93f4835b3@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): Comparing compile performance for current master (with TTG) and after reverting. 1. Check timing on home.smart-cactus.org, for current master at 25f36bd7ba6899be6c720292528c56bc35e0f089 a. Make mk/validate.mk which overrides the mk/flavours/validate.mk one Set: `GhcStage2HcOpts = -ddump-timings -O -dcore-lint -dno-debug- output` b. Run {{{#!sh $ make maintainer-clean $ CPUS=6 ./validate >> master-validate.log 2>&1 }}} 2. Revert the prior TTG commits on branch `wip/revert-ttg-2017-11-20` GHC/master - 438dd1cbba13d35f3452b4dcef3f94ce9a216905 - e3ec2e7ae94524ebd111963faf34b84d942265b4 - 47ad6578ea460999b53eb4293c3a3b3017a56d65 haddock/ghc-head - 01eeeb048acd2dd05ff6471ae148a97cf0720547 - 73a26af844ac50b8bec39de11d64452a6286b00c - 9f054dc365379c66668de6719840918190ae6e44 - 134a7bb054ea730b13c8629a76232d73e3ace049 3. Run the timing again {{{#!sh $ make maintainer-clean $ CPUS=6 ./validate >> revert-validate.log 2>&1 }}} Results to follow -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 21:37:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 21:37:02 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.6e15deadd41f5d1de7ddf29ba3614946@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): The raw log files from the previous measurements are - https://www.dropbox.com/s/pjk5yd46uiv32y5/master-validate.log.gz?dl=0 - https://www.dropbox.com/s/vcsbiyu977mxmlh/revert-validate.log.gz?dl=0 I am not sure of the master-validate, the box may have been busy doing other builds while it ran. I will analyze in the morning. Feel free to dive in if you like, timezones are great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 22:37:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 22:37:26 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory In-Reply-To: <044.e21e37476590d999c81ca942af908658@haskell.org> References: <044.e21e37476590d999c81ca942af908658@haskell.org> Message-ID: <059.e7fbceef8281a197a5d865adc878118f@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: memory ulimit Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by luispedro): The current behaviour is to start at 1TB and divide by 2 until success (or failure if it cannot allocate at least 1MB): https://github.com/ghc/ghc/blob/25f36bd7ba6899be6c720292528c56bc35e0f089/rts/posix/OSMem.c#L517 If the memory available is in between two multiples of 2, then this can lead to a lot of unused memory. A (not so implausible, I think our systems might run something similar) worst-case scenario is running on a system with 1T of RAM, but where the sysadmin has wisely chosen to reserve 1GB for a monitoring process. Now, a whole 511GB of RAM are wasted! Btw, that code mentions https://ghc.haskell.org/trac/ghc/ticket/10877 with a previous discussion on this issue. A simple solution is to replace `*len /= 2` by `*len -= *len/8`. The max number of calls to mmap() goes up from 14 to 67, but wastage is now at most 1/8th of the final allocated memory. (Another question is whether a GHC compiled programme could access >1TB of RAM? We now have a few 4TB machines and more on the way...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 22:39:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 22:39:55 -0000 Subject: [GHC] #14488: Can't define a lens for a field with a constraint In-Reply-To: <048.86e8973d2180c36f750acacdcb0d1f12@haskell.org> References: <048.86e8973d2180c36f750acacdcb0d1f12@haskell.org> Message-ID: <063.6d47a24ed32160e0783f0a95a1b595e7@haskell.org> #14488: Can't define a lens for a field with a constraint -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.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): Phab:D4213 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks! Can someone pls commit? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 20 22:46:33 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Nov 2017 22:46:33 -0000 Subject: [GHC] #14493: Why is g++ necessary to compile GHC? In-Reply-To: <046.f6ec23ebd8a585358047482b310433b0@haskell.org> References: <046.f6ec23ebd8a585358047482b310433b0@haskell.org> Message-ID: <061.71e545fed555b9bf708f7f9ccba61dfc@haskell.org> #14493: Why is g++ necessary to compile GHC? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by simonpj): But does libffi really NEED a C++ preprocessor? Or is it accidental? If deliberate, then yes, let's just document it. Even if accidental, perhpas it's in a code base we don't control in which case we are stuck with it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 00:04:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 00:04:41 -0000 Subject: [GHC] #14488: Can't define a lens for a field with a constraint In-Reply-To: <048.86e8973d2180c36f750acacdcb0d1f12@haskell.org> References: <048.86e8973d2180c36f750acacdcb0d1f12@haskell.org> Message-ID: <063.091e6ec9349ed063c505eb21e881ba3a@haskell.org> #14488: Can't define a lens for a field with a constraint -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T14488 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4213 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => typecheck/should_compile/T14488 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 00:10:39 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 00:10:39 -0000 Subject: [GHC] #14496: Invoking GHC 8.2.1 executable anywhere results in access violation on Windows 10 Message-ID: <050.8ec2c012a4031c145e18d1e0d7cbdd1d@haskell.org> #14496: Invoking GHC 8.2.1 executable anywhere results in access violation on Windows 10 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC doesn't work Unknown/Multiple | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This apparently started to happen somewhat recently, as I've been able to run GHC 8.2.1 on Windows before. (Perhaps it was a recent update that changed things?) In any case, any attempt to run GHC or GHCi 8.2.1 immediately results in an access violation, and always at the same memory location: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.1 $ ghc Access violation in generated code when reading 000000001170399e $ ghci WARNING: GHCi invoked via 'ghci.exe' in MinTTY consoles (e.g., Cygwin or MSYS) doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper instead GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Access violation in generated code when reading 000000001170399e }}} Strangely enough, GHC 8.0.2 and older do not suffer from this issue, just 8.2.1. In case it's useful, here's the `strace` output: {{{ $ strace ghc Access violation in generated code when reading 000000001170399e create_child: ghc --- Process 10324 created --- Process 10324 loaded C:\Windows\System32\ntdll.dll at 00007ffa31280000 --- Process 10324 loaded C:\Windows\System32\kernel32.dll at 00007ffa31170000 --- Process 10324 loaded C:\Windows\System32\KernelBase.dll at 00007ffa2dd40000 --- Process 10324 loaded C:\Windows\System32\apphelp.dll at 00007ffa2b500000 --- Process 10324 loaded C:\Windows\System32\AcLayers.dll at 00007ffa03630000 --- Process 10324 loaded C:\Windows\System32\msvcrt.dll at 00007ffa30ab0000 --- Process 10324 loaded C:\Windows\System32\user32.dll at 00007ffa2e850000 --- Process 10324 loaded C:\Windows\System32\win32u.dll at 00007ffa2dba0000 --- Process 10324 loaded C:\Windows\System32\gdi32.dll at 00007ffa2ec30000 --- Process 10324 loaded C:\Windows\System32\gdi32full.dll at 00007ffa2da00000 --- Process 10324 loaded C:\Windows\System32\msvcp_win.dll at 00007ffa2d960000 --- Process 10324 loaded C:\Windows\System32\ucrtbase.dll at 00007ffa2dbc0000 --- Process 10324 loaded C:\Windows\System32\shlwapi.dll at 00007ffa2e7f0000 --- Process 10324 loaded C:\Windows\System32\combase.dll at 00007ffa30e50000 --- Process 10324 loaded C:\Windows\System32\rpcrt4.dll at 00007ffa2e9e0000 --- Process 10324 loaded C:\Windows\System32\bcryptprimitives.dll at 00007ffa2dcc0000 --- Process 10324 loaded C:\Windows\System32\sfc.dll at 0000000180000000 --- Process 10324 loaded C:\Windows\System32\winspool.drv at 00007ffa1db00000 --- Process 10324 loaded C:\Windows\System32\IPHLPAPI.DLL at 00007ffa2cb90000 --- Process 10324 loaded C:\Windows\System32\bcrypt.dll at 00007ffa2d0d0000 --- Process 10324 loaded C:\Windows\System32\sfc_os.dll at 00007ffa1c2e0000 --- Process 10324 loaded C:\Windows\System32\imm32.dll at 00007ffa31220000 --- Process 10324 loaded C:\Windows\System32\shell32.dll at 00007ffa2ef80000 --- Process 10324 loaded C:\Windows\System32\cfgmgr32.dll at 00007ffa2e700000 --- Process 10324 thread 3948 created --- Process 10324 loaded C:\Windows\System32\SHCore.dll at 00007ffa30cf0000 --- Process 10324 loaded C:\Windows\System32\windows.storage.dll at 00007ffa2dfb0000 --- Process 10324 loaded C:\Windows\System32\advapi32.dll at 00007ffa30da0000 --- Process 10324 loaded C:\Windows\System32\sechost.dll at 00007ffa2eb00000 --- Process 10324 thread 4764 created --- Process 10324 loaded C:\Windows\System32\kernel.appcore.dll at 00007ffa2d660000 --- Process 10324 loaded C:\Windows\System32\powrprof.dll at 00007ffa2d5f0000 --- Process 10324 loaded C:\Windows\System32\profapi.dll at 00007ffa2d5d0000 --- Process 10324 thread 3852 created --- Process 10324 loaded C:\Windows\System32\wsock32.dll at 00007ffa1c2b0000 --- Process 10324 loaded C:\Windows\System32\ws2_32.dll at 00007ffa2ef10000 --- Process 10324 loaded C:\Windows\System32\ws2_32.dll at 0000000000150000 --- Process 10324 unloaded DLL at 0000000000150000 --- Process 10324 thread 4872 created --- Process 10324 thread 5780 created --- Process 10324 thread 8360 created --- Process 10324, exception c0000005 at 00007ffa3129c12e --- Process 10324 thread 8360 exited with status 0x1 --- Process 10324 thread 5780 exited with status 0x1 --- Process 10324 thread 4872 exited with status 0x1 --- Process 10324 thread 3852 exited with status 0x1 --- Process 10324 thread 4764 exited with status 0x1 --- Process 10324 thread 3948 exited with status 0x1 --- Process 10324 exited with status 0x1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 00:14:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 00:14:04 -0000 Subject: [GHC] #14493: Why is g++ necessary to compile GHC? In-Reply-To: <046.f6ec23ebd8a585358047482b310433b0@haskell.org> References: <046.f6ec23ebd8a585358047482b310433b0@haskell.org> Message-ID: <061.70f6e17fc59a3e6cc276b8df01cec543@haskell.org> #14493: Why is g++ necessary to compile GHC? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by bgamari): I can't speak to whether it needs a C++ preprocessor. That being said, it is indeed a codebase which we have no control over. Moreover, it is sadly rather under-maintained so getting them to drop the dependency if it's not needed will be difficult. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 00:14:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 00:14:58 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.856d0c6d0fd2d791681347a2d233aaa2@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by simonpj): What about Plan F: no `Data` instances at all? Easy to implement, very fast to compile. GHC doesn't use them. (Or at least only in ways we could do some other way.) They are there only to support hypothetical clients. Or maybe not. It'd be good to knonw who is using them. Otherwise, disgusgintly, yes perhaps Plan B is best. PS: sorry about the red herring of Plans C and D. Utterly bogus. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 00:29:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 00:29:26 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory In-Reply-To: <044.e21e37476590d999c81ca942af908658@haskell.org> References: <044.e21e37476590d999c81ca942af908658@haskell.org> Message-ID: <059.6ad4c354983a22b48613bac584745860@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: memory ulimit Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Jaffacake (added) * milestone: => 8.4.1 Comment: > A simple solution is to replace `*len /= 2` by `*len -= *len/8`. The max number of calls to `mmap()` goes up from 14 to 67, but wastage is now at most 1/8th of the final allocated memory. Indeed this sounds like a pretty simple solution. I don't even think the increase in number of `mmap` calls is all that bad since these are failed `mmap`s, so they shouldn't incur the usual overhead. What do you think, simonmar? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 00:43:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 00:43:02 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory In-Reply-To: <044.e21e37476590d999c81ca942af908658@haskell.org> References: <044.e21e37476590d999c81ca942af908658@haskell.org> Message-ID: <059.4603bd0f9724fdf6a39b0b6dcad1129b@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: memory ulimit Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4215 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D4215 Comment: Here is a quick patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 00:43:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 00:43:10 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory In-Reply-To: <044.e21e37476590d999c81ca942af908658@haskell.org> References: <044.e21e37476590d999c81ca942af908658@haskell.org> Message-ID: <059.d81a00068cc653dc7077860a684b1551@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: memory ulimit Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4215 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 01:03:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 01:03:22 -0000 Subject: [GHC] #14460: Symlink resolving fails against SMB mounts In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.1f692031e756c930c4f0756844d072f3@haskell.org> #14460: Symlink resolving fails against SMB mounts -------------------------------------+------------------------------------- Reporter: astert | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4216 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D4216 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 06:37:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 06:37:46 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.e8d10c7f159b29d43a297385ef9c2602@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): The performance change (in compile time) is here: https://perf.haskell.org/ghc/#compare/25f36bd7ba6899be6c720292528c56bc35e0f089/11954bd8d7f26c1f34b4277f971899454a791aba From 2413 to 2059 seconds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 06:39:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 06:39:24 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.21dd297d3f928f412dced1d68b039882@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): I made a very quick attempt yesterday at removing the Data instances completely, but they are in fact used, I introduced them for the dump AST stuff. I want to first get an idea of what the major performance driver is, before focusing exclusively on instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 09:04:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 09:04:13 -0000 Subject: [GHC] #13630: ByteString pinned memory can be leaky In-Reply-To: <042.fff951e1f463505474531ee41ed62718@haskell.org> References: <042.fff951e1f463505474531ee41ed62718@haskell.org> Message-ID: <057.6faca7a29b067b077f9a72982b3e7ce6@haskell.org> #13630: ByteString pinned memory can be leaky -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.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 snoyberg): * cc: snoyberg (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 09:44:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 09:44:02 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals In-Reply-To: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> References: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> Message-ID: <062.0bc064c9c35f43ec3803d044a43681a8@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: AndreasK Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: 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:D4218 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * owner: (none) => AndreasK * priority: high => normal * differential: => Phab:D4218 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 10:56:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 10:56:35 -0000 Subject: [GHC] #14496: Invoking GHC 8.2.1 executable anywhere results in access violation on Windows 10 In-Reply-To: <050.8ec2c012a4031c145e18d1e0d7cbdd1d@haskell.org> References: <050.8ec2c012a4031c145e18d1e0d7cbdd1d@haskell.org> Message-ID: <065.ca9b3dc447cd4d169412ec3ba4a37d18@haskell.org> #14496: Invoking GHC 8.2.1 executable anywhere results in access violation on Windows 10 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | 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 Phyx-): Could you use https://docs.microsoft.com/en- us/sysinternals/downloads/procdump to generate a crash dump for me? using `-t -ma`. Also what's your OS version? (use powershell and `Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, ServicePackMajorVersion, OSArchitecture | Format-List *` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 12:15:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 12:15:11 -0000 Subject: [GHC] #14497: internal error: scavenge_one: strange object 19828 Message-ID: <044.d9e9a438baea314f437751a66a161d85@haskell.org> #14497: internal error: scavenge_one: strange object 19828 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'll attach the test program. Reproduces each time. {{{ $ ./test Nothing test: internal error: scavenge_one: strange object 19828 Stack trace: 0x4b27df set_initial_registers (rts/Libdw.c:288.0) 0x7fe51b3fcd48 dwfl_thread_getframes (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x7fe51b3fd22c dwfl_getthread_frames (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x4b2ddd libdwGetBacktrace (rts/Libdw.c:259.0) 0x49883b rtsFatalInternalErrorFn (rts/RtsMessages.c:169.0) 0x4989ed barf (rts/RtsMessages.c:47.0) 0x4b3f8c scavenge_one (rts/sm/Scav.c:1615.0) 0x4b4e91 scavenge_loop1 (rts/sm/Scav.c:2066.0) 0x49d517 scavenge_until_all_done (rts/sm/GC.c:1017.0) 0x49dde4 GarbageCollect (rts/sm/GC.c:412.0) 0x4969a3 scheduleDoGC (rts/Schedule.c:1827.0) 0x49776c schedule (rts/Schedule.c:558.0) 0x49811c scheduleWorker (rts/Schedule.c:2582.0) 0x7fe51b835494 start_thread (/build/glibc- tnXPha/glibc-2.24/nptl/pthread_create.c:333.0) 0x7fe51b113abf __clone (../sysdeps/unix/sysv/linux/x86_64/clone.S:99.0) (GHC version 8.2.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 12:15:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 12:15:30 -0000 Subject: [GHC] #14497: internal error: scavenge_one: strange object 19828 In-Reply-To: <044.d9e9a438baea314f437751a66a161d85@haskell.org> References: <044.d9e9a438baea314f437751a66a161d85@haskell.org> Message-ID: <059.d42dcdd70f1849dafe692a57f6e82b3f@haskell.org> #14497: internal error: scavenge_one: strange object 19828 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Yuras): * Attachment "test.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 12:20:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 12:20:28 -0000 Subject: [GHC] #14497: internal error: scavenge_one: strange object 19828 In-Reply-To: <044.d9e9a438baea314f437751a66a161d85@haskell.org> References: <044.d9e9a438baea314f437751a66a161d85@haskell.org> Message-ID: <059.3dd32c1669ea4a47acb83b841eaccaa3@haskell.org> #14497: internal error: scavenge_one: strange object 19828 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Yuras): * Attachment "test2.hs" added. This simplified version produces different object type: strange object 781 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 12:37:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 12:37:42 -0000 Subject: [GHC] #14496: Invoking GHC 8.2.1 executable anywhere results in access violation on Windows 10 In-Reply-To: <050.8ec2c012a4031c145e18d1e0d7cbdd1d@haskell.org> References: <050.8ec2c012a4031c145e18d1e0d7cbdd1d@haskell.org> Message-ID: <065.7667d2d2bc095a6e0a7b5b8c9ea9a404@haskell.org> #14496: Invoking GHC 8.2.1 executable anywhere results in access violation on Windows 10 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | 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 RyanGlScott): Replying to [comment:1 Phyx-]: > Could you use https://docs.microsoft.com/en- us/sysinternals/downloads/procdump to generate a crash dump for me? using `-t -ma`. Here's the PowerShell output: {{{ $ .\Procdump\procdump64.exe -t -ma -e 1 -x . C:\Users\RyanGlScott\Software\ghc-8.2.1\bin\ghc.exe ProcDump v9.0 - Sysinternals process dump utility Copyright (C) 2009-2017 Mark Russinovich and Andrew Richards Sysinternals - www.sysinternals.com Process: ghc.exe (9372) CPU threshold: n/a Performance counter: n/a Commit threshold: n/a Threshold seconds: n/a Hung window check: Disabled Log debug strings: Disabled Exception monitor: First Chance+Unhandled Exception filter: [Includes] * [Excludes] Terminate monitor: Enabled Cloning type: Disabled Concurrent limit: n/a Avoid outage: n/a Number of dumps: 1 Dump folder: .\ Dump filename/mask: PROCESSNAME_YYMMDD_HHMMSS Queue to WER: Disabled Kill after dump: Disabled Press Ctrl-C to end monitoring without terminating the process. [07:35:22] Exception: C0000005.ACCESS_VIOLATION [07:35:22] Dump 1 initiated: .\ghc.exe_171121_073522.dmp [07:35:24] Dump 1 writing: Estimated dump file size is 124 MB. [07:35:26] Dump 1 complete: 124 MB written in 4.0 seconds Access violation in generated code when reading 000000001170399e [07:35:27] Dump count reached. }}} I'll attach the full log separately. > Also what's your OS version? (use powershell and `Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, ServicePackMajorVersion, OSArchitecture | Format-List *` {{{ $ Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, ServicePackMajorVersion, OSArchitecture | Format-List * Caption : Microsoft Windows 10 Home Version : 10.0.16299 ServicePackMajorVersion : 0 OSArchitecture : 64-bit }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 12:55:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 12:55:17 -0000 Subject: [GHC] #14496: Invoking GHC 8.2.1 executable anywhere results in access violation on Windows 10 In-Reply-To: <050.8ec2c012a4031c145e18d1e0d7cbdd1d@haskell.org> References: <050.8ec2c012a4031c145e18d1e0d7cbdd1d@haskell.org> Message-ID: <065.7462da2b49fb116cae9a412dc9fda37f@haskell.org> #14496: Invoking GHC 8.2.1 executable anywhere results in access violation on Windows 10 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | 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 RyanGlScott): The dump file is too large to attach, so here's a link: https://www.dropbox.com/s/efm2pmm6t3875g9/ghc.exe_171121_073522.dmp?dl=0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 13:22:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 13:22:17 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.f6b5f1e3df48a16a245f21d4e798e8fe@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): Having just leveled up on `Turtle`, the compile time differences for compiling stage2 (via `-ddump-timings`) are attached, together with the programme used to generate them. The key result is the following {{{ Module : master reverted diff HsSyn : 10154.82 1550.70 8604.12 HsImpExp : 16266.68 4703.24 11563.44 DynFlags : 70682.66 59097.39 11585.27 HsLit : 21915.48 4487.74 17427.74 HsPat : 26660.85 7181.77 19479.08 HsTypes : 107182.37 16066.12 91116.25 HsBinds : 115097.57 19346.81 95750.76 HsExpr : 260980.84 38087.04 222893.79 HsDecls : 320157.08 45702.17 274454.90 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 13:23:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 13:23:29 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.cb386f0ef309e0655747ae59f2c81c65@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Changes (by alanz): * Attachment "differences.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 13:23:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 13:23:46 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.bd33875c50df86fc9a1adc9f638d685a@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Changes (by alanz): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 13:25:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 13:25:17 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.483206c1ba877b5188f3663d324b2230@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): And I guess I should do the same with the version where the deriving is all in one file, to isolate that too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 13:25:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 13:25:38 -0000 Subject: [GHC] #14497: internal error: scavenge_one: strange object 19828 In-Reply-To: <044.d9e9a438baea314f437751a66a161d85@haskell.org> References: <044.d9e9a438baea314f437751a66a161d85@haskell.org> Message-ID: <059.630532f5d96b44f87a876a299982dcc7@haskell.org> #14497: internal error: scavenge_one: strange object 19828 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's worth noting that one must compile the program with `-O1` or `-O2` to trigger this panic (i.e., `-O0` isn't sufficient). Also, the panic itself only seems to appear on GHC 8.2.1 and HEAD. With 8.0.2 and older, you can still run the program, but the two forked computations never appear to return. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 14:04:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 14:04:08 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" Message-ID: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- {{{#!hs {-# Language PatternSynonyms, ViewPatterns, GADTs, ConstraintKinds, RankNTypes, KindSignatures, PolyKinds, ScopedTypeVariables, DataKinds #-} import Type.Reflection import Data.Kind data Dict c where Dict :: c => Dict c asTypeable :: TypeRep a -> Dict (Typeable a) asTypeable rep = withTypeable rep Dict pattern Typeable :: () => Typeable a => TypeRep a pattern Typeable <- (asTypeable -> Dict) where Typeable = typeRep data N = O | S N type SN = (TypeRep :: N -> Type) pattern SO = (Typeable :: TypeRep (O::N)) pattern SS :: forall (t :: k'). () => forall (a :: kk -> k') (n :: kk). (t ~ a n) => TypeRep n -> TypeRep t pattern SS n <- (App (Typeable :: TypeRep (a::kk -> k')) n) }}} fails with **GHC internal error** {{{ $ ghci -ignore-dot-ghci Bug.hs GHCi, version 8.3.20170920: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:31:47: error: • GHC internal error: ‘kk’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a1Ao :-> Type variable ‘k'’ = k' :: *, a1Aq :-> Type variable ‘t’ = t :: k', a1Hs :-> Type variable ‘a’ = a :: k0, r1v4 :-> Identifier[asTypeable::forall k (a :: k). TypeRep a -> Dict (Typeable a), TopLevelLet]] • In the kind ‘kk -> k'’ In the first argument of ‘TypeRep’, namely ‘(a :: kk -> k')’ In the type ‘TypeRep (a :: kk -> k')’ | 31 | pattern SS n <- (App (Typeable :: TypeRep (a::kk -> k')) n) | ^^ Failed, 0 modules loaded. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 14:07:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 14:07:34 -0000 Subject: [GHC] #13210: Can't run terminfo code in GHCi on Windows In-Reply-To: <050.4b925adbb480c97661debe69ca3ada51@haskell.org> References: <050.4b925adbb480c97661debe69ca3ada51@haskell.org> Message-ID: <065.cf73a708464039efbb0ff5b3e326a1f0@haskell.org> #13210: Can't run terminfo code in GHCi on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3154 Wiki Page: | Phab:D3155 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: Phyx- => (none) * status: closed => new * resolution: fixed => Comment: Alas, it seems like this code is once again broken. On GHC 8.2.1 and 8.2.2-rc3, running: {{{ $ runghc -lncursesw Terminfo.hs }}} In MSYS2 simply exits early with exit code 127, and in PowerShell, it crashes with the following pop-up window: {{{ [Window Title] ghc.exe [Main Instruction] ghc.exe has stopped working [Content] A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available. [Close program] }}} Using Phyx-'s modified GHC 8.3 build, running that same command produces a stack trace: {{{ $ ..\..\..\Software\ghc-8.3.20171021\bin\runghc -lncursesw .\Terminfo.hs Access violation in generated code when reading 0xffffffffffffffff Attempting to reconstruct a stack trace... Frame Code address * 0x87af500 0x7ffa30adefc4 C:\WINDOWS\System32\msvcrt.dll+0x2efc4 * 0x87af540 0x7ffa30adf074 C:\WINDOWS\System32\msvcrt.dll+0x2f074 * 0x87af548 0xa275038 C:\msys64\mingw64\lib\libncursesw.a(db_iterator.o)+0x68 (_nc_tic_dir+0x118) * 0x87af550 0x10 * 0x87af558 0x398 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 14:22:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 14:22:59 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.ddf20a8912a3bb93c84855e3c4074e60@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): Hmm. It's clear that `t` and `k'` from the pattern signature should scope over the pattern declaration, by the usual rules (top level forall'd variables from the signature do scope in this way). But what about the existentials, `a` and `kk`? I think it would make sense for them to scope too, in the same way. Does everyone agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 14:34:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 14:34:02 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.dcd2a8d9782c6bff18095468c40e3815@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => PatternSynonyms * failure: None/Unknown => Compile-time crash or panic * component: Compiler => Compiler (Type checker) * related: => #14288 Comment: Yes, `kk` should definitely scope over the pattern synonym body. In fact, the only reason that it doesn't currently is due to #14288 (that is, `ScopedTypeVariables` doesn't pick up variables from nested `forall`s). I suspect fixing #14288 would quite naturally lead to a solution to this bug as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 14:34:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 14:34:24 -0000 Subject: [GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 In-Reply-To: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> References: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> Message-ID: <069.d8cb1976b78c79e6f6e6ba5cd7540650@haskell.org> #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14498 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14498 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 15:05:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 15:05:57 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.c34fa378c82f5799c58e6325be122712@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah, indeed comment:6 of #14288 concerns exactly this point. Short term: GHC should not crash. Maybe it should just reject the program. Slightly longer term: we need to decide if we want to adopt the proposal in commment:15 of #14288. Would this be worth a short GHC proposal? It's certainly a change in the surface language. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 15:19:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 15:19:08 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.5d748e851534753469053f5598f2ecde@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:3 simonpj]: > Short term: GHC should not crash. Maybe it should just reject the program. I agree that until we implement #14288, this shouldn't crash. In fact, given that `kk` doesn't technically scope over the pattern at the moment, I'm surprised that GHC doesn't come up with a fresh `kk` type variable in the pattern `(App (Typeable :: TypeRep (a::kk -> k')) n)` (in fact, if you change it to `(App (Typeable :: TypeRep (a::kk2 -> k')) n)`, then it compiles). This makes me suspect that the code which renamed pattern synonyms is doing something suspicious at the moment. > Slightly longer term: we need to decide if we want to adopt the proposal in commment:15 of #14288. Would this be worth a short GHC proposal? It's certainly a change in the surface language. To answer your two questions: * Yes. I've been lacking the free time to look at comment:15 of #14288, but perhaps I can take a look this week. * I suppose we could put this forth as a proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 15:30:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 15:30:43 -0000 Subject: [GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 In-Reply-To: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> References: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> Message-ID: <069.7f893c279fd4a2e7df37772f2932dda9@haskell.org> #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14498 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 15:41:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 15:41:34 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.06c429fecc6c2f40f0b7fd6e6a09f7c5@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's a much simpler way to reproduce the bug, for debugging purposes: {{{#!hs {-# LANGUAGE PatternSynonyms, PolyKinds, ScopedTypeVariables #-} module Bug where import Data.Proxy pattern Foo :: forall (a :: j). () => forall (b :: k). () => Proxy a pattern Foo = (Proxy :: Proxy (b :: k)) }}} {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:7:37: error: • GHC internal error: ‘k’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a1vz :-> Type variable ‘j’ = j, a1vB :-> Type variable ‘a’ = a, a1vD :-> Type variable ‘b’ = b] • In the kind ‘k’ In the first argument of ‘Proxy’, namely ‘(b :: k)’ In the type ‘Proxy (b :: k)’ | 7 | pattern Foo = (Proxy :: Proxy (b :: k)) | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 16:18:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 16:18:40 -0000 Subject: [GHC] #14499: Pattern synonym, (a::k) cannot be written (a::N) given (k ~ N) Message-ID: <051.64908da2f864ad440fb7f37aba87bd58@haskell.org> #14499: Pattern synonym, (a::k) cannot be written (a::N) given (k ~ N) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 was trying to create a pattern synonym that matches `TypeRep (a::k)` when `k ~ N`, witnessing the equality and returning the representation. This works fine: {{{#!hs {-# Language PatternSynonyms, ViewPatterns, GADTs, ConstraintKinds, RankNTypes, KindSignatures, PolyKinds, ScopedTypeVariables, DataKinds, TypeInType, TypeOperators, TypeApplications #-} import Type.Reflection import Data.Kind foo :: forall (kind::k') (a::k). TypeRep kind -> TypeRep a -> Maybe (kind :~~: k, TypeRep a) foo krep rep = do HRefl <- eqTypeRep krep (typeRepKind rep) pure (HRefl, rep) data N = O | S N pattern Bloop :: forall (a::k). () => N~k => TypeRep (a::k) -> TypeRep (a::k) pattern Bloop rep <- (foo (typeRep @N) -> Just (HRefl, rep :: TypeRep (a::N))) where Bloop rep = rep }}} Note that I have annotated `rep :: TypeRep (a::N)` in the view pattern, which is the first argument to `Bloop`. Let's reflect that in the type {{{#!hs -- error: -- • Expected kind ‘N’, but ‘a’ has kind ‘k’ -- • In the first argument of ‘TypeRep’, namely ‘(a :: N)’ -- In the type ‘TypeRep (a :: N) -> TypeRep (a :: k)’ -- | -- 15 | pattern Bloop :: forall (a::k). () => N ~ k => TypeRep (a::N) -> TypeRep (a::k) -- | ^ pattern Bloop :: forall (a::k). () => N~k => TypeRep (a::N) -> TypeRep (a::k) pattern Bloop rep <- (foo (typeRep @N) -> Just (rep, HRefl)) where Bloop rep = rep }}} Oh no, GHC complains that `a::k` (not `a::N`) but we have local knowledge that `N ~ k`. I know the rules for kinds are weird so I don't know if this is intended. A way around this is quantifying over an existential variable that is heterogeneously equal to `a`: {{{#!hs pattern Bloop :: forall (a::k). () => forall (n::N). a~~n => TypeRep (n::N) -> TypeRep (a::k) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 16:34:19 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 16:34:19 -0000 Subject: [GHC] #14057: Upstream Alpine Linux distribution patches In-Reply-To: <046.942a17c3b70d9863c708d25f4b0f2dde@haskell.org> References: <046.942a17c3b70d9863c708d25f4b0f2dde@haskell.org> Message-ID: <061.c02ba5d0a78ee88fe3625de84bba1e8c@haskell.org> #14057: Upstream Alpine Linux distribution patches ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.0.1 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: | ---------------------------------+---------------------------------------- Old description: > Alpine Linux has a variety of > [[https://git.alpinelinux.org/cgit/aports/tree/community/ghc?h=3.6-stable|patches]] > to allow GHC to build against the musl libc implementation. Let's get > these upstream. > > Here is my take on the patches: > > * `0000-alpine.patch`: This is a no-brainer. Will gladly accept. > * `0000-bootstrap.patch`: I really don't know about this one. The > motivation is quite unclear. Needs discussion. > * `0001-rm-ghc-pwd.patch`: Already merged in > 4c56ad36ee0d1f8b6f1b2bc0d8fff1c9acd1a389. > * `0002-Correct-issue-with-libffi-and-glibc.patch`: This is, > unfortunately, a `libffi` fix, not a GHC fix. I'm not enthusiastic about > patching libffi like this. However, `libffi`'s upstream is quite > unresponsive and we are waiting for them to act on a number of issues, so > perhaps we'll need to reconsider this. I've created #14056 to track this. > * `0003-do-not-use-SHELL.patch`: Looks reasonable to me. > * `0004-reproducible-tmp-names.patch`: Seems plausible. > * `0005-buildpath-abi-stability.patch`: There's some discussion in > #10424. > * `0006-fix-madvise.patch`: Merged in > 6576bf83cdf4eac05eb88a24aa934a736c91e3da. See #12865 > * `0007-build-hp2ps-twice.patch`, `0008-build-unlit-twice.patch`: Why? New description: Alpine Linux has a variety of [[https://git.alpinelinux.org/cgit/aports/tree/community/ghc?h=3.6-stable|patches]] to allow GHC to build against the musl libc implementation. Let's get these upstream. Here is my take on the patches: * `0000-alpine.patch`: This is a no-brainer. Merged as 9ae24bb615416b3e8d972d45ebe3dd281242d213. * `0000-bootstrap.patch`: I really don't know about this one. The motivation is quite unclear. Needs discussion. * `0001-rm-ghc-pwd.patch`: Already merged in 4c56ad36ee0d1f8b6f1b2bc0d8fff1c9acd1a389. * `0002-Correct-issue-with-libffi-and-glibc.patch`: This is, unfortunately, a `libffi` fix, not a GHC fix. I'm not enthusiastic about patching libffi like this. However, `libffi`'s upstream is quite unresponsive and we are waiting for them to act on a number of issues, so perhaps we'll need to reconsider this. I've created #14056 to track this. * `0003-do-not-use-SHELL.patch`: Looks reasonable to me. Merged as a10c2e6e9e9af3addbf91c0bb374257fb6c72553. * `0004-reproducible-tmp-names.patch`: Seems plausible. * `0005-buildpath-abi-stability.patch`: There's some discussion in #10424. * `0006-fix-madvise.patch`: Merged in 6576bf83cdf4eac05eb88a24aa934a736c91e3da. See #12865 * `0007-build-hp2ps-twice.patch`, `0008-build-unlit-twice.patch`: Why? -- Comment (by bgamari): `0000-alpine.patch` and `0003-do-not-use-SHELL.patch` were merged for 8.4.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 16:46:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 16:46:33 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2314500=3A_Coercion_artifact_=E2=80=98cobox?= =?utf-8?q?=E2=80=99_appears_in_error_message?= Message-ID: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> #14500: Coercion artifact ‘cobox’ appears in error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- {{{#!hs {-# Language PatternSynonyms, ViewPatterns, GADTs, ConstraintKinds, RankNTypes, KindSignatures, PolyKinds, ScopedTypeVariables, DataKinds, TypeInType, TypeOperators, TypeApplications #-} import Type.Reflection foo :: forall (kind::k') (a::k). TypeRep kind -> TypeRep a -> Maybe (kind :~~: k, TypeRep a) foo krep rep = undefined data N = O | S N pattern Bloop' :: forall k' (a::k). Typeable k' => k':~~:k -> TypeRep (a::k) -> TypeRep (a::k) pattern Bloop' hrefl rep <- (foo (typeRep @k') -> Just (hrefl, rep)) pattern SO :: forall (a::kk). () => N~kk => TypeRep (a::kk) pattern SO <- Bloop' (HRefl::N:~~:kk) () }}} Coercion artifact `cobox` appears in the error message {{{ $ ghci -ignore-dot-ghci -fprint-explicit-coercions /tmp/Bug.hs GHCi, version 8.3.20170920: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Bug.hs, interpreted ) /tmp/Bug.hs:14:39: error: • Couldn't match type ‘()’ with ‘TypeRep (a |> cobox)’ Expected type: TypeRep a Actual type: () • In the pattern: () In the pattern: Bloop' (HRefl :: N :~~: kk) () In the declaration for pattern synonym ‘SO’ | 14 | pattern SO <- Bloop' (HRefl::N:~~:kk) () | ^^ Failed, 0 modules loaded. Prelude> }}} This may be intentional but the user guide says they are meant to be internal, so I'm double checking. > Using `-fprint-explicit-coercions` makes GHC print coercions in types. When trying to prove the equality between types of different kinds, GHC uses type-level coercions. Users will rarely need to see these, as they are meant to be internal. > > [https://downloads.haskell.org/~ghc/master/users-guide/using.html#ghc- flag--fprint-explicit-coercions GHC User Guide] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 16:49:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 16:49:15 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDUwMDogQ29lcmNpb24gYXJ0aWZhY3Qg4oCY?= =?utf-8?q?cobox=E2=80=99_appears_in_error_message?= In-Reply-To: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> References: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> Message-ID: <066.d00accf1d87ce601f586795b0bed9df5@haskell.org> #14500: Coercion artifact ‘cobox’ appears in error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Iceland_jack): More output: Replacing it with {{{#!hs pattern SO <- Bloop' (HRefl::N:~~:kk) (typeRep :: TypeRep O) }}} gives {{{ /tmp/Bug.hs:14:40: error: • Could not deduce: a ~ ('O |> Sym cobox) from the context: (* ~ *, kk ~ N) bound by a pattern with constructor: HRefl :: forall k1 (a :: k1). a :~~: a, in a pattern synonym declaration at /tmp/Bug.hs:14:23-27 ‘a’ is a rigid type variable bound by the signature for pattern synonym ‘SO’ at /tmp/Bug.hs:13:23 Expected type: TypeRep a Actual type: TypeRep 'O • When checking that the pattern signature: TypeRep 'O fits the type of its context: TypeRep a In the pattern: typeRep :: TypeRep O In the pattern: Bloop' (HRefl :: N :~~: kk) (typeRep :: TypeRep O) | 14 | pattern SO <- Bloop' (HRefl::N:~~:kk) (typeRep::TypeRep O) | ^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 16:53:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 16:53:23 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDUwMDogQ29lcmNpb24gYXJ0aWZhY3Qg4oCY?= =?utf-8?q?cobox=E2=80=99_appears_in_error_message?= In-Reply-To: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> References: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> Message-ID: <066.83e712fdc316f056e7d4f0d0f460f108@haskell.org> #14500: Coercion artifact ‘cobox’ appears in error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 goldfire): That's very odd. Are you sure you don't have `-fprint-explicit-coercions` on? (I don't have a good GHC to test with at the moment.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 16:58:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 16:58:56 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDUwMDogQ29lcmNpb24gYXJ0aWZhY3Qg4oCY?= =?utf-8?q?cobox=E2=80=99_appears_in_error_message?= In-Reply-To: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> References: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> Message-ID: <066.a5bc5f4a3f0227c3ae3ee56f54201fab@haskell.org> #14500: Coercion artifact ‘cobox’ appears in error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Iceland_jack): I do pass `-fprint-explicit-coercions` to ghci so it's wasn't a shock to me to find a coercion :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 17:04:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 17:04:13 -0000 Subject: [GHC] #14501: hp2ps and unlit are compiled by the stage0 compiler Message-ID: <046.d2c7325ab6aa360259cb4180f4cc3fba@haskell.org> #14501: hp2ps and unlit are compiled by the stage0 compiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.2.1 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 looking at #14057 I noticed that the hp2ps and unlit binaries that we install are both produced by the stage0 compiler. This will almost certainly break during cross-compilation and it generally breaks release hygiene. We should fix this in Hadrian (assuming angerman hasn't fixed it already). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 17:04:24 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 17:04:24 -0000 Subject: [GHC] #14057: Upstream Alpine Linux distribution patches In-Reply-To: <046.942a17c3b70d9863c708d25f4b0f2dde@haskell.org> References: <046.942a17c3b70d9863c708d25f4b0f2dde@haskell.org> Message-ID: <061.1f97384e200a53f817da2419ef270c58@haskell.org> #14057: Upstream Alpine Linux distribution patches ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.0.1 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 bgamari): I have posted `0004-reproducible-tmp-names.patch` as Phab:D4220. The remaining patches are: * `0000-bootstrap.patch`: This seems quite suspicious. Moreover, it very likely won't be needed in Hadrian. * `0002-Correct-issue-with-libffi-and-glibc.patch`: Someone is going to need to take ownership of this to get it upstreamed into `libffi` * `0005-buildpath-abi-stability.patch`: This doesn't seem like a reasonable approach as it kills potentially useful information in the interface file. Either we should find a way to encode this information in a deterministic way (e.g. module name and unit ID) or remove it entirely if it really isn't necessary * `0007-build-hp2ps-twice.patch`, `0008-build-unlit-twice.patch`: Looking at these again, they actually look fairly reasonable. In general we shouldn't pollute the final build artifacts with things produced by the bootstrap toolchain. I would say we should just fix this in Hadrian. I've opened #14501 to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 17:05:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 17:05:33 -0000 Subject: [GHC] #14501: hp2ps and unlit are compiled by the stage0 compiler In-Reply-To: <046.d2c7325ab6aa360259cb4180f4cc3fba@haskell.org> References: <046.d2c7325ab6aa360259cb4180f4cc3fba@haskell.org> Message-ID: <061.434c1cb2301ceaeb0c5ce9806fc16a1a@haskell.org> #14501: hp2ps and unlit are compiled by the stage0 compiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.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: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > In looking at #14057 I noticed that the hp2ps and unlit binaries that we > install are both produced by the stage0 compiler. This will almost > certainly break during cross-compilation and it generally breaks release > hygiene. We should fix this in Hadrian (assuming angerman hasn't fixed it > already). New description: In looking at #14057 I noticed that the hp2ps and unlit binaries that we install are both produced by the stage0 compiler. This will almost certainly break during cross-compilation and generally breaks release hygiene. We should fix this in Hadrian (assuming angerman hasn't fixed it already). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 17:08:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 17:08:18 -0000 Subject: [GHC] #14502: Build Alpine Linux binary distributions Message-ID: <046.7faa39537281abdbe7789c4ce9416be8@haskell.org> #14502: Build Alpine Linux binary distributions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Continuous | Version: 8.2.1 Integration | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: 14057 Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At least three people have come to me asking for Alpine Linux bindists. Given that Alpine is a fair bit different from most other distributions and can be useful in containers, this seems fairly reasonable to me. Terrorjack has some useful-looking automation at https://github.com/TerrorJack/meikyu. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 17:13:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 17:13:48 -0000 Subject: [GHC] #14497: internal error: scavenge_one: strange object 19828 In-Reply-To: <044.d9e9a438baea314f437751a66a161d85@haskell.org> References: <044.d9e9a438baea314f437751a66a161d85@haskell.org> Message-ID: <059.911f779a38e6487155521baf559b29c9@haskell.org> #14497: internal error: scavenge_one: strange object 19828 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Yuras): * cc: simonmar (added) * priority: normal => high * milestone: => 8.2.2 Comment: Then it is a regression, right? Please feel free to lower priority/change milestone if you disagree. I played with it a bit. Looks like it is not related neither to `ST`, no to concurrent evaluation of the same thunk. But resuming a thunk after blackholing is completely broken. Once I even got <> exception thrown in each child thread. Disaster. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 17:16:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 17:16:20 -0000 Subject: [GHC] #14497: internal error: scavenge_one: strange object 19828 In-Reply-To: <044.d9e9a438baea314f437751a66a161d85@haskell.org> References: <044.d9e9a438baea314f437751a66a161d85@haskell.org> Message-ID: <059.6fb7d41d826333814fd2dea098099891@haskell.org> #14497: internal error: scavenge_one: strange object 19828 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.2.2 => 8.4.1 Comment: Well one thing's for certain: this isn't going to make it into 8.2.2, as that ship's already sailed. Whether or not this is a regression is debatable, as this program has never done the correct thing (on old versions, it would simply never finish the forked computations, whereas now the problem is more readily apparent). I'll mark this for the 8.4.1 milestone to be on the safe side. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 17:18:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 17:18:06 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDUwMDogQ29lcmNpb24gYXJ0aWZhY3Qg4oCY?= =?utf-8?q?cobox=E2=80=99_appears_in_error_message?= In-Reply-To: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> References: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> Message-ID: <066.407e8f44a42b552a268fcefaa1f953d7@haskell.org> #14500: Coercion artifact ‘cobox’ appears in error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 RyanGlScott): I'm confused. You explicitly pass `-fprint-explicit-coercions`, and lo and behold, coercions appear in error messages. What exactly is the bug here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 17:21:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 17:21:11 -0000 Subject: [GHC] #14497: internal error: scavenge_one: strange object 19828 In-Reply-To: <044.d9e9a438baea314f437751a66a161d85@haskell.org> References: <044.d9e9a438baea314f437751a66a161d85@haskell.org> Message-ID: <059.4faf8f0eab7fc779212c74c8a59c03cf@haskell.org> #14497: internal error: scavenge_one: strange object 19828 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * milestone: 8.4.1 => 8.2.3 Comment: Ahh good, another puzzle. Marking for 8.2.3 just in case such a release happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 17:28:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 17:28:40 -0000 Subject: [GHC] #14499: Pattern synonym, (a::k) cannot be written (a::N) given (k ~ N) In-Reply-To: <051.64908da2f864ad440fb7f37aba87bd58@haskell.org> References: <051.64908da2f864ad440fb7f37aba87bd58@haskell.org> Message-ID: <066.02eae11c4abf60a833c4e6e748258cd9@haskell.org> #14499: Pattern synonym, (a::k) cannot be written (a::N) given (k ~ N) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12677 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12677 Comment: Yes indeed. Here is a simpler version of the issue you've encountered: {{{#!hs {-# LANGUAGE DataKinds, GADTs, PolyKinds, ScopedTypeVariables #-} import Data.Proxy data N = O | S N data Foo (a :: k) where MkFoo :: forall (a :: k). N ~ k => Proxy (a :: N) -> Foo a }}} Here, GHC complains: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:8:45: error: • Expected kind ‘N’, but ‘a1’ has kind ‘k1’ • In the first argument of ‘Proxy’, namely ‘(a :: N)’ In the type ‘Proxy (a :: N)’ In the definition of data constructor ‘MkFoo’ | 8 | MkFoo :: forall (a :: k). N ~ k => Proxy (a :: N) -> Foo a | ^ }}} Despite the fact that GHC is supposed to know that `N ~ k`. Alas, this is due to an unfortunate limitation in how GHC's type system works. I'll quote Richard's comment [https://ghc.haskell.org/trac/ghc/ticket/12677#comment:2 here]: > This is a hard one to fix, surprisingly. The problem is that you've declared `a` to have type `k` and then used `a` as an argument to `->`. Of course, `->` expects a `Type`. So GHC should insert add a cast, forming `a |> η`, for the argument to `->`. The problem is that this would require using the equality proof for `Type ~ k` as the body of `η`, and the current type system simply does not allow this. [https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Internal#Liftedvs.Unliftedequality ​Here] are some notes on the matter, though they were not written to be digested by anyone but me. > > I don't expect this will be fixed until we have `-XDependentTypes`. **tl;dr** GHC's type system probably won't be smart enough to figure this out until dependent types are added. See #12677 for details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 17:29:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 17:29:44 -0000 Subject: [GHC] #14503: Killing a thread will block if there is another process reading from a handle Message-ID: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> #14503: Killing a thread will block if there is another process reading from a handle ----------------------------------------+--------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- When trying to kill a thread, the program (which uses a thread) hangs if there is another process trying to read from a handle. This bug can be reproduced with using [https://github.com/capitanbatata/sandbox/tree/master/dangling-connections this sample code]. I'll explain the relevant details below. I have the following Haskell code: {{{#!hs someFuncWithChans :: IO () someFuncWithChans = withSocketsDo $ do h <- connectTo "localhost" (PortNumber 9090) hSetBuffering h NoBuffering ch <- newChan putStrLn "Starting the handler reader" readerTid <- forkIO $ handleReader h ch cmdsHandler h ch putStrLn "Killing the handler reader" killThread readerTid putStrLn "Closing the handle" hClose h cmdsHandler :: Handle -> Chan Action -> IO () cmdsHandler h ch = do act <- readChan ch case act of Quit -> putStrLn "Bye bye" Line line -> do hPutStrLn h (reverse line) cmdsHandler h ch handleReader :: Handle -> Chan Action -> IO () handleReader h ch = forever $ do line <- strip <$> hGetLine h case line of "quit" -> writeChan ch Quit _ -> writeChan ch (Line line) data Action = Quit | Line String }}} Is the function `someFuncWithChans` is run along with the following Java program, then the former will block while killing the handler reader (`readerTid`). {{{#!java public static void main(String[] args) throws IOException, InterruptedException { ServerSocket serverSock = new ServerSocket(9090); Socket sock = serverSock.accept(); InputStream inStream = sock.getInputStream(); BufferedReader sockIn = new BufferedReader(new InputStreamReader(inStream)); OutputStream outStream = sock.getOutputStream(); PrintWriter sockOut = new PrintWriter(new OutputStreamWriter(outStream)); while (true) { Thread.sleep(1000); System.out.println("Sending foo"); sockOut.println("foo"); sockOut.flush(); String s = sockIn.readLine(); System.out.println("Got " + s ); Thread.sleep(1000); System.out.println("Sending bar"); sockOut.println("bar"); sockOut.flush(); s = sockIn.readLine(); System.out.println("Got " + s ); Thread.sleep(1000); System.out.println("Sending quit"); sockOut.println("quit"); sockOut.flush(); // This will cause someFuncWithChans to block when killing the // reader thread. s = sockIn.readLine(); System.out.println("Got " + s ); } } }}} If the `sockIn.readLine()` is commented out, then killing the thread will succeed. This problem appears only on my Windows machine (at work), whereas it does not on my personal Linux machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 18:31:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 18:31:33 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDUwMDogQ29lcmNpb24gYXJ0aWZhY3Qg4oCY?= =?utf-8?q?cobox=E2=80=99_appears_in_error_message?= In-Reply-To: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> References: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> Message-ID: <066.fc24ef85828390fa098a14fceff5454a@haskell.org> #14500: Coercion artifact ‘cobox’ appears in error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 goldfire): Perhaps you're disturbed by the name `cobox`? But how is that any worse than the `a` and `t` type variables that GHC routinely comes up with? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 18:32:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 18:32:51 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.fe6845c880cccda6d55012529c049283@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): I was also wondering if we could more easily derive `Generic`, and use that for any needed traversals. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 19:51:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 19:51:11 -0000 Subject: [GHC] #14504: Nofib is broken on Windows Message-ID: <046.cc1daf3bad5a64611f515c88109eb2f4@haskell.org> #14504: Nofib is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: NoFib | Version: 8.2.1 benchmark suite | 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 seems like nofib is currently broken on Windows. Specifically, it fails for me with {{{ ... /home/ben/ghc/inplace/bin/ghc-stage2 -M -dep-suffix "" -dep-makefile .depend -osuf o -O2 -Rghc-timing -H32m -hisuf hi -rtsopts -XBangPatterns -O2 Main.hs <> Finished making boot in fannkuch-redux: 0 ------------------------------------------------------------------------ == make boot --no-print-directory; in /home/ben/ghc/nofib/shootout/fasta ------------------------------------------------------------------------ $topdir/../mingw/bin/gcc.exe -std=gnu99 -O3 -fomit-frame-pointer fasta-c.c -o fasta-c /bin/sh: /../mingw/bin/gcc.exe: No such file or directory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 19:51:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 19:51:22 -0000 Subject: [GHC] #14504: Nofib is broken on Windows In-Reply-To: <046.cc1daf3bad5a64611f515c88109eb2f4@haskell.org> References: <046.cc1daf3bad5a64611f515c88109eb2f4@haskell.org> Message-ID: <061.829462ce7ef781750b0c99b17d554107@haskell.org> #14504: Nofib is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: NoFib benchmark | Version: 8.2.1 suite | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 20:22:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 20:22:37 -0000 Subject: [GHC] #14497: internal error: scavenge_one: strange object 19828 In-Reply-To: <044.d9e9a438baea314f437751a66a161d85@haskell.org> References: <044.d9e9a438baea314f437751a66a161d85@haskell.org> Message-ID: <059.8226ffdb1050882ca73d133cf9af26a6@haskell.org> #14497: internal error: scavenge_one: strange object 19828 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * cc: duog (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 20:46:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 20:46:15 -0000 Subject: [GHC] #14456: Windows runtime linker failure with icuuc In-Reply-To: <050.3b07902cfc2f558e6740649e9c204478@haskell.org> References: <050.3b07902cfc2f558e6740649e9c204478@haskell.org> Message-ID: <065.4029c2ee98ecb28f114d93b0edf2478e@haskell.org> #14456: Windows runtime linker failure with icuuc -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Those patterns won't work, the one you want is `-llibicuuc`, those two are the ones missing from https://github.com/ghc/ghc/blob/master/compiler/ghci/Linker.hs#L1390 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 21:17:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 21:17:52 -0000 Subject: [GHC] #14504: Nofib is broken on Windows In-Reply-To: <046.cc1daf3bad5a64611f515c88109eb2f4@haskell.org> References: <046.cc1daf3bad5a64611f515c88109eb2f4@haskell.org> Message-ID: <061.f845832115acd11af26736f15d78ac86@haskell.org> #14504: Nofib is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: NoFib benchmark | Version: 8.2.1 suite | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): It's broken because `ghc --info` doesn't expand `$topdir` as one would expect it to. {{{ > ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","$topdir/../mingw/bin/gcc.exe") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("Haskell CPP command","$topdir/../mingw/bin/gcc.exe") ,("Haskell CPP flags","-E -undef -traditional ") ,("ld command","$topdir/../mingw/bin/ld.exe") }}} It used work only by accident because of my earlier bug which emitted hard-coded paths in the settings file. Looks like the bug here is that GHC doesn't report something useful for `--info`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 21:49:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 21:49:31 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.94d71c3e01fa104c288214267d1fe195@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"314bc31489f1f4cd69e913c3b1e33236b2bdf553/ghc" 314bc314/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="314bc31489f1f4cd69e913c3b1e33236b2bdf553" Revert "trees that grow" work As documented in #14490, the Data instances currently blow up compilation time by too much to stomach. Alan will continue working on this in a branch and we will perhaps merge to 8.2 before 8.2.1 to avoid having to perform painful cherry-picks in 8.2 minor releases. Reverts haddock submodule. This reverts commit 47ad6578ea460999b53eb4293c3a3b3017a56d65. This reverts commit e3ec2e7ae94524ebd111963faf34b84d942265b4. This reverts commit 438dd1cbba13d35f3452b4dcef3f94ce9a216905. This reverts commit 0ff152c9e633accca48815e26e59d1af1fe44ceb. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 22:15:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 22:15:42 -0000 Subject: [GHC] #14497: internal error: scavenge_one: strange object 19828 In-Reply-To: <044.d9e9a438baea314f437751a66a161d85@haskell.org> References: <044.d9e9a438baea314f437751a66a161d85@haskell.org> Message-ID: <059.d8db681757101464c0089835559de44c@haskell.org> #14497: internal error: scavenge_one: strange object 19828 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 22:36:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 22:36:16 -0000 Subject: [GHC] #14497: internal error: scavenge_one: strange object 19828 In-Reply-To: <044.d9e9a438baea314f437751a66a161d85@haskell.org> References: <044.d9e9a438baea314f437751a66a161d85@haskell.org> Message-ID: <059.3dbe82402821b59a1e4481b7e910024a@haskell.org> #14497: internal error: scavenge_one: strange object 19828 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): If I change `fuc` to {{{#!hs fuc n = product (force [1..n]) }}} then I can't reproduce the problem. This suggests that the (presumably rather large) stack allocation in Yuras's version may be relevant in some fashion, I imagine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 23:41:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 23:41:23 -0000 Subject: [GHC] #14485: Typo in blog post. In-Reply-To: <045.139435f6984ca4dc271d75d35c0e6487@haskell.org> References: <045.139435f6984ca4dc271d75d35c0e6487@haskell.org> Message-ID: <060.fbe797b6cdba0c623c456615e8678bca@haskell.org> #14485: Typo in blog post. -------------------------------------+------------------------------------- Reporter: bmusin | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: typo 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 bgamari): Thanks, fixed! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 21 23:41:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Nov 2017 23:41:31 -0000 Subject: [GHC] #14485: Typo in blog post. In-Reply-To: <045.139435f6984ca4dc271d75d35c0e6487@haskell.org> References: <045.139435f6984ca4dc271d75d35c0e6487@haskell.org> Message-ID: <060.a31deefd1f989cbcf96b9634b9fabc1a@haskell.org> #14485: Typo in blog post. -------------------------------------+------------------------------------- Reporter: bmusin | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: Component: Documentation | Version: 8.2.1 Resolution: fixed | Keywords: typo 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 bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 00:27:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 00:27:32 -0000 Subject: [GHC] #14505: CircleCI only builds pushed heads Message-ID: <046.5fc442bf07e9d8a0060fa53efebf8332@haskell.org> #14505: CircleCI only builds pushed heads -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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 appears that CircleCI only builds the head commit of pushes. This means that most of our commits are currently going untested. It seems that the ability to build all commits has been an outstanding feature request since February 2017. See, * https://stackoverflow.com/questions/42074618/circleci-build-all- commits-between-last * https://discuss.circleci.com/t/manually-trigger-a-build-all-commits- between-two-revisions/10160/2 It seems like our options are currently to either ensure that people only push on commit at a time or develop some automation to manually trigger commits using the [[https://circleci.com/docs/api/v1-reference/#new- build|API]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 00:27:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 00:27:52 -0000 Subject: [GHC] #14506: Configure Harbormaster to trigger CircleCI commits Message-ID: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> #14506: Configure Harbormaster to trigger CircleCI commits -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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 Wed Nov 22 00:53:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 00:53:20 -0000 Subject: [GHC] #14505: CircleCI only builds pushed heads In-Reply-To: <046.5fc442bf07e9d8a0060fa53efebf8332@haskell.org> References: <046.5fc442bf07e9d8a0060fa53efebf8332@haskell.org> Message-ID: <061.4a7aa6ea0391441f59d3c07cc4e79930@haskell.org> #14505: CircleCI only builds pushed heads -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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): Unfortunately it looks like the API is [[https://discuss.circleci.com/t/creating-a-new-workflow-based-build-via- api-mysteriously-fails/18280|buggy]] and consequently the second option is off the table, at least for the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 01:03:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 01:03:16 -0000 Subject: [GHC] #14507: Core Lint error with Type.Reflection and pattern synonyms Message-ID: <051.39dfd28e6e1a32cce4d4d43aea87a71e@haskell.org> #14507: Core Lint error with Type.Reflection and pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language PatternSynonyms, ViewPatterns, GADTs, ConstraintKinds, RankNTypes, KindSignatures, PolyKinds, ScopedTypeVariables, DataKinds, TypeInType, TypeOperators, TypeApplications, TypeFamilies, TypeFamilyDependencies #-} import Type.Reflection import Prelude import Data.Kind data Dict c where Dict :: c => Dict c data N = O | S N foo :: forall (kind::k') (a::k). TypeRep kind -> TypeRep a -> Maybe (kind :~~: k, TypeRep a) foo krep rep = do HRefl <- eqTypeRep krep (typeRepKind rep) pure (HRefl, rep) pattern Bloop' :: forall k' (a::k). Typeable k' => k':~~:k -> TypeRep (a::k) -> TypeRep (a::k) pattern Bloop' hrefl rep <- (foo (typeRep @k') -> Just (hrefl, rep)) where Bloop' HRefl rep = rep type family SING = (res :: k -> Type) | res -> k where -- Core Lint error disappears with this line: SING = (TypeRep :: N -> Type) pattern RepN :: forall (a::kk). Typeable a => N~kk => SING a -> TypeRep (a::kk) pattern RepN tr <- Bloop' (HRefl::N:~~:kk) (tr :: TypeRep (a::N)) where RepN tr = tr asTypeable :: TypeRep a -> Dict (Typeable a) asTypeable rep = withTypeable rep Dict pattern TypeRep :: () => Typeable a => TypeRep a pattern TypeRep <- (asTypeable -> Dict) where TypeRep = typeRep -- error pattern SO = RepN TypeRep }}} triggers “Core Lint errors” on 8.2.1, 8.3.20170920 when run with `ghci -ignore-dot-ghci -dcore-lint`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 01:03:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 01:03:51 -0000 Subject: [GHC] #14507: Core Lint error with Type.Reflection and pattern synonyms In-Reply-To: <051.39dfd28e6e1a32cce4d4d43aea87a71e@haskell.org> References: <051.39dfd28e6e1a32cce4d4d43aea87a71e@haskell.org> Message-ID: <066.235360f22f9f85dba4b5e594a6f70b02@haskell.org> #14507: Core Lint error with Type.Reflection and pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 Iceland_jack): * Attachment "core-dump.log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 01:06:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 01:06:34 -0000 Subject: [GHC] #14508: Bring up Appveyor for Windows CI Message-ID: <046.b1e7fd0356de10b29814d8db318f756c@haskell.org> #14508: Bring up Appveyor for Windows CI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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 current plan is to move to Appveyor for CI on Windows. Mateusz has a first [[https://github.com/tweag/ghc/blob/tweag/circleci- macos/appveyor.yml|stab]] at a configuration. Unfortunately it looks like we will far-exceed the one-hour default build time limit. It appears they Appveyor [[https://github.com/appveyor/ci/issues/517 |does give]] extensions to open-source projects, but typically only extend to 1.5 hours. It's unlikely that this will be sufficient as even my local Windows builds take ~1.75 hours. It appears that Rust has found a way around this as their [[https://ci.appveyor.com/project/rust-lang/rust/history|builds]] routinely last ~2 hours. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 01:07:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 01:07:09 -0000 Subject: [GHC] #14508: Bring up Appveyor for Windows CI In-Reply-To: <046.b1e7fd0356de10b29814d8db318f756c@haskell.org> References: <046.b1e7fd0356de10b29814d8db318f756c@haskell.org> Message-ID: <061.71685ef901b5e0c9eb58a5656def0215@haskell.org> #14508: Bring up Appveyor for Windows CI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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: > The current plan is to move to Appveyor for CI on Windows. > > Mateusz has a first [[https://github.com/tweag/ghc/blob/tweag/circleci- > macos/appveyor.yml|stab]] at a configuration. Unfortunately it looks like > we will far-exceed the one-hour default build time limit. It appears they > Appveyor [[https://github.com/appveyor/ci/issues/517 > |does give]] extensions to open-source projects, but typically only > extend to 1.5 hours. It's unlikely that this will be sufficient as even > my local Windows builds take ~1.75 hours. > > It appears that Rust has found a way around this as their > [[https://ci.appveyor.com/project/rust-lang/rust/history|builds]] > routinely last ~2 hours. New description: The current plan is to move to Appveyor for CI on Windows. Mateusz has a first [[https://github.com/tweag/ghc/blob/tweag/circleci- macos/appveyor.yml|stab]] at a configuration. Unfortunately it looks like we will far-exceed the one-hour default build time limit. It appears they Appveyor [[https://github.com/appveyor/ci/issues/517|does give]] extensions to open-source projects, but typically only extend to 1.5 hours. It's unlikely that this will be sufficient as even my local Windows builds take ~1.75 hours. It appears that Rust has found a way around this as their [[https://ci.appveyor.com/project/rust-lang/rust/history|builds]] routinely last ~2 hours. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 01:12:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 01:12:13 -0000 Subject: [GHC] #14508: Bring up Appveyor for Windows CI In-Reply-To: <046.b1e7fd0356de10b29814d8db318f756c@haskell.org> References: <046.b1e7fd0356de10b29814d8db318f756c@haskell.org> Message-ID: <061.5e709278fb0dffaeabd62f0d17d856f4@haskell.org> #14508: Bring up Appveyor for Windows CI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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): I have confirmed with the Rustaceans that Mozilla indeed pays for their Appveyor usage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 01:31:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 01:31:52 -0000 Subject: [GHC] #14346: 8.2.1 regression: heap corruption after safe foreign calls In-Reply-To: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> References: <049.7a4af7d8399ac93444ea4b9211bf91ff@haskell.org> Message-ID: <064.9b629fa27331af62df12005ee9075b44@haskell.org> #14346: 8.2.1 regression: heap corruption after safe foreign calls -------------------------------------+------------------------------------- Reporter: andrewchen | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * blockedby: 14375 => Comment: I'm going to close this since the serious correctness issue is resolved for now. A more efficient solution will come in 8.4 (#14375). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 01:34:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 01:34:28 -0000 Subject: [GHC] #14506: Configure Harbormaster to trigger CircleCI commits In-Reply-To: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> References: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> Message-ID: <061.1566e0ab7ba7c01883cffe2ae534f99d@haskell.org> #14506: Configure Harbormaster to trigger CircleCI commits -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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): Unfortunately it appears that the CircleCI only supports repositories hosted on GitHub: https://phabricator.haskell.org/harbormaster/build/38022/. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 01:39:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 01:39:48 -0000 Subject: [GHC] #14509: Consider adding new stg_ap_* functions Message-ID: <047.f71c564d666dce2500d09c50b1230aac@haskell.org> #14509: Consider adding new stg_ap_* functions -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime | Version: 8.2.1 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: -------------------------------------+------------------------------------- Currently, the RTS has a fixed set of `stg_ap_*` functions. There are two problems with this: 1. All programs pay for these functions, even programs that don’t use them. Furthermore, it is not possible for new ones to be generated by GHC for certain cases. 2. The set included in the RTS may not be optimal. (1) is a lot of work, but dealing with (2) should be “just” a matter of hunting down which functions would be useful. I would start with ByteString, Text, and other highly optimized libraries, some of which (such as ByteString) are very widely used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 01:42:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 01:42:44 -0000 Subject: [GHC] #14508: Bring up Appveyor for Windows CI In-Reply-To: <046.b1e7fd0356de10b29814d8db318f756c@haskell.org> References: <046.b1e7fd0356de10b29814d8db318f756c@haskell.org> Message-ID: <061.6163112ccdfd5770a57cf1034c3a1379@haskell.org> #14508: Bring up Appveyor for Windows CI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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 dobenour): Is there some reason we can’t use Jenkens? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 01:48:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 01:48:43 -0000 Subject: [GHC] #14507: Core Lint error with Type.Reflection and pattern synonyms In-Reply-To: <051.39dfd28e6e1a32cce4d4d43aea87a71e@haskell.org> References: <051.39dfd28e6e1a32cce4d4d43aea87a71e@haskell.org> Message-ID: <066.5c9165ebc37db72450cf9c2aa7878406@haskell.org> #14507: Core Lint error with Type.Reflection and pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: | -------------------------------------+------------------------------------- Comment (by dobenour): You should ''never'' get a failure in Core Lint, so this is definitely a bug. Moving to highest priority. This is obviously a bug in either the type checker or the desugarer. Either the type checker is accepting garbage or the desugarer is messing up. My instinct says to blame the desugarer – a type variable out of scope doesn’t make any sense at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 01:49:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 01:49:02 -0000 Subject: [GHC] #14507: Core Lint error with Type.Reflection and pattern synonyms In-Reply-To: <051.39dfd28e6e1a32cce4d4d43aea87a71e@haskell.org> References: <051.39dfd28e6e1a32cce4d4d43aea87a71e@haskell.org> Message-ID: <066.4ef70b9cf085ef6d92fe2973fb68a275@haskell.org> #14507: Core Lint error with Type.Reflection and pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.2.1 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 dobenour): * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 02:00:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 02:00:57 -0000 Subject: [GHC] #14508: Bring up Appveyor for Windows CI In-Reply-To: <046.b1e7fd0356de10b29814d8db318f756c@haskell.org> References: <046.b1e7fd0356de10b29814d8db318f756c@haskell.org> Message-ID: <061.985d5340b30b8793147482924fa40b4e@haskell.org> #14508: Bring up Appveyor for Windows CI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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): Several members of the newly formed GHC Devops Committee argued strongly against Jenkins. Their arguments are summarized on wiki:ContinuousIntegration -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 02:02:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 02:02:12 -0000 Subject: [GHC] #14510: GHC.ExecutionStack.showStackTrace broken Message-ID: <043.9685830b69e2246f2b96ccff19455218@haskell.org> #14510: GHC.ExecutionStack.showStackTrace broken -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- When compiled with the dwarf bindist of 8.2.2 with {{{ ghc --make -g testdwarf.hs }}} The following is output: {{{ testdwarf: Failed to get stack frames of current process: no matching address range: Success }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 02:02:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 02:02:27 -0000 Subject: [GHC] #14509: Consider adding new stg_ap_* functions In-Reply-To: <047.f71c564d666dce2500d09c50b1230aac@haskell.org> References: <047.f71c564d666dce2500d09c50b1230aac@haskell.org> Message-ID: <062.683712196678a3864fcd04f8fe720b02@haskell.org> #14509: Consider adding new stg_ap_* functions -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.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 bgamari): The approach sounds plausible to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 02:02:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 02:02:31 -0000 Subject: [GHC] #14510: GHC.ExecutionStack.showStackTrace broken In-Reply-To: <043.9685830b69e2246f2b96ccff19455218@haskell.org> References: <043.9685830b69e2246f2b96ccff19455218@haskell.org> Message-ID: <058.44e91d8691114ea42dcdf75cb99577bf@haskell.org> #14510: GHC.ExecutionStack.showStackTrace broken -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 duog): * Attachment "testdwarf.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 02:11:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 02:11:30 -0000 Subject: [GHC] #14488: Can't define a lens for a field with a constraint In-Reply-To: <048.86e8973d2180c36f750acacdcb0d1f12@haskell.org> References: <048.86e8973d2180c36f750acacdcb0d1f12@haskell.org> Message-ID: <063.129bee430444ac39f7e8a98c1a1d1c76@haskell.org> #14488: Can't define a lens for a field with a constraint -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T14488 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4213 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0db4627b8baf3255cf16725f8acdd69e27f0ab85/ghc" 0db4627/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0db4627b8baf3255cf16725f8acdd69e27f0ab85" Test Trac #14488 Summary: The refactoring in 3f5673f34a2f761423027bf46f64f7499708725f also fixed a previously unreported issue in the typechecker that prevented defining a lens to a record field with a constraint. This patch adds a regression test. Test Plan: make test TEST=14488 Reviewers: bgamari Reviewed By: bgamari Subscribers: int-e, rwbarton, thomie GHC Trac Issues: #14488 Differential Revision: https://phabricator.haskell.org/D4213 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 02:11:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 02:11:30 -0000 Subject: [GHC] #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) In-Reply-To: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> References: <049.0b02f45f092991ff71d90010f90c58a1@haskell.org> Message-ID: <064.06b9583b25e34f3bff4e63b68e202b93@haskell.org> #14257: Heap profiling with ghc and hp2ps and strict function application ($!) gives samples out of sequence (regression) -------------------------------------+------------------------------------- Reporter: carlostome | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: fixed | Keywords: profiler Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14257 Blocked By: | Blocking: Related Tickets: #14006, #11645 | Differential Rev(s): Phab:D4184 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bb2a08e1d9e4d6740f82bc2f3a844bd97bfc4a24/ghc" bb2a08e1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bb2a08e1d9e4d6740f82bc2f3a844bd97bfc4a24" testsuite: Add test for #14257 Subscribers: rwbarton, thomie, duog GHC Trac Issues: #14257 Differential Revision: https://phabricator.haskell.org/D4201 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 02:11:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 02:11:57 -0000 Subject: [GHC] #14488: Can't define a lens for a field with a constraint In-Reply-To: <048.86e8973d2180c36f750acacdcb0d1f12@haskell.org> References: <048.86e8973d2180c36f750acacdcb0d1f12@haskell.org> Message-ID: <063.5c96ab38ac9e911f103562b9da6ee441@haskell.org> #14488: Can't define a lens for a field with a constraint -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T14488 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4213 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 02:12:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 02:12:47 -0000 Subject: [GHC] #14510: GHC.ExecutionStack.showStackTrace broken In-Reply-To: <043.9685830b69e2246f2b96ccff19455218@haskell.org> References: <043.9685830b69e2246f2b96ccff19455218@haskell.org> Message-ID: <058.8fc22e825fcfeae5251817ef3ae70090@haskell.org> #14510: GHC.ExecutionStack.showStackTrace broken ---------------------------------+-------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | ---------------------------------+-------------------------------------- Changes (by duog): * version: 8.2.2 => 8.2.1 * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => x86_64 (amd64) Comment: Happens with 8.2.1 as well, so I must assume there's a problem with my configuration. Ubuntu 16.04 libdw-dev Version: 0.165-3ubuntu1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 02:26:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 02:26:37 -0000 Subject: [GHC] #14504: Nofib is broken on Windows In-Reply-To: <046.cc1daf3bad5a64611f515c88109eb2f4@haskell.org> References: <046.cc1daf3bad5a64611f515c88109eb2f4@haskell.org> Message-ID: <061.28bc3d6ea00b0a1b3bb16559dca27125@haskell.org> #14504: Nofib is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: NoFib benchmark | Version: 8.2.1 suite | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4222 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4222 Comment: This should be addressed by Phab:D4222. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 02:47:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 02:47:58 -0000 Subject: [GHC] #14437: Optimise remainders by powers of two In-Reply-To: <047.291113040ac7c3813fee479e4d1a965e@haskell.org> References: <047.291113040ac7c3813fee479e4d1a965e@haskell.org> Message-ID: <062.9f6a621c6b2aedfd7e65438becb1fa85@haskell.org> #14437: Optimise remainders by powers of two -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: Bodigrim Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.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): Phab:D4180 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"23116dfee485902cb3c26640e38f62032bebe72d/ghc" 23116df/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="23116dfee485902cb3c26640e38f62032bebe72d" cmm: Optimise remainders by powers of two Test Plan: validate Reviewers: bgamari, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14437 Differential Revision: https://phabricator.haskell.org/D4180 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 02:47:58 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 02:47:58 -0000 Subject: [GHC] #14439: Remove redundant subtraction in (^) and stimes In-Reply-To: <047.009e2be896b30621f9e70dd019b082b1@haskell.org> References: <047.009e2be896b30621f9e70dd019b082b1@haskell.org> Message-ID: <062.916ba6635b163f06c7ea62742f95b5a8@haskell.org> #14439: Remove redundant subtraction in (^) and stimes -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 8.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): Phab:D4173 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"eb5a40cea6c64f5300c7697231cb0ede2c554388/ghc" eb5a40ce/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eb5a40cea6c64f5300c7697231cb0ede2c554388" base: Remove redundant subtraction in (^) and stimes Subtraction `y - 1` is redundant. The value of y is guaranteed to be positive and odd, so ``` (y - 1) `quot` 2` = `y `quot` 2 ``` Test Plan: validate Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14439 Differential Revision: https://phabricator.haskell.org/D4173 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 02:56:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 02:56:32 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.c29f85ab48609ff329aa5008f7164e27@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by Shayan-Najd): > but they are in fact used, I introduced them for the dump AST stuff. Moving towards Plan F (no `Data` instances), does GHC itself use "the dump AST stuff", or is it to be used for debugging (and in GHC API)? If not used within GHC, we can temporarily disable remove them (and the related test cases) and time the build time, before and after applying the TTG patches in this `Data`-less branch. Does it sound reasonable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 03:17:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 03:17:04 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.96ac08cd3e0b521b256567e2e183f8a8@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by bgamari): There are a few uses other than the AST dumping. While discussing this with Simon I was able to find one in `RdrHsSyn` by grepping `Data.Data` and looking through some of the uses. However, on closer inspection it looks like I just got lucky as that is the only use I can see in `compiler/`. However, I suspect haddock uses SYB. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 03:18:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 03:18:36 -0000 Subject: [GHC] #14437: Optimise remainders by powers of two In-Reply-To: <047.291113040ac7c3813fee479e4d1a965e@haskell.org> References: <047.291113040ac7c3813fee479e4d1a965e@haskell.org> Message-ID: <062.2599f84ac2f93bf1a2849ec1550b9397@haskell.org> #14437: Optimise remainders by powers of two -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: Bodigrim Type: feature request | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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:D4180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 03:18:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 03:18:43 -0000 Subject: [GHC] #14439: Remove redundant subtraction in (^) and stimes In-Reply-To: <047.009e2be896b30621f9e70dd019b082b1@haskell.org> References: <047.009e2be896b30621f9e70dd019b082b1@haskell.org> Message-ID: <062.b947c04fdb231c4516405a668eefa4a5@haskell.org> #14439: Remove redundant subtraction in (^) and stimes -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 8.2.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:D4173 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 03:24:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 03:24:52 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.b6afbf491495e6f0419add15aaf1c78e@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by Shayan-Najd): I see. The goal is to simply see whether really `Data` instances are causing all performance issues. Can we still build GHC without haddock working? If yes, then measuring compile-time of a `data`-less branch before and after TTG patches answers many of our questions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 04:20:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 04:20:27 -0000 Subject: [GHC] #14506: Configure Harbormaster to trigger CircleCI builds (was: Configure Harbormaster to trigger CircleCI commits) In-Reply-To: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> References: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> Message-ID: <061.7058c224bec8d737490caae3568a2788@haskell.org> #14506: Configure Harbormaster to trigger CircleCI builds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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 Wed Nov 22 05:56:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 05:56:54 -0000 Subject: [GHC] #14511: indexArray# getting poorly deferred Message-ID: <046.562c7ba6b9fb319f3069f981d147d69c@haskell.org> #14511: indexArray# getting poorly deferred -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 both of the following functions I am attempting to execute a read from an `Array# a` and then write the result to a `MutableArray# s a`, and I would like the following evaluation properties: * the `a` value is not forced, i.e. the value stored in the `MutableArray# s a` will remain a thunk if the original value in the `Array# a` was; and * the new `MutableArray#` does not maintain any references to the original `Array#`, so that the original can be GCed. The singleton-unboxed-tuple return type of `indexArray#` appears to be there to allow specifically this use case, but sadly it only succeeds for the first of these functions. The second function ends up storing a thunk in the `MutableArray#` which contains a reference to the `Array#`. Haskell: {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} module IndexThenWrite where import GHC.Prim indexThenWrite :: Array# a -> MutableArray# s a -> State# s -> State# s indexThenWrite arr marr s = case indexArray# arr 123# of (# a #) -> writeArray# marr 234# a s indexThenWriteF :: (a -> b) -> Array# a -> MutableArray# s b -> State# s -> State# s indexThenWriteF f arr marr s = case indexArray# arr 123# of (# a #) -> writeArray# marr 234# (f a) s }}} Core: {{{#!hs -- RHS size: {terms: 15, types: 18, coercions: 0, joins: 0/0} indexThenWrite indexThenWrite = \ @ a_aq9 @ s_aqa arr_apa marr_apb s1_apc -> case indexArray# arr_apa 123# of { (# ipv_sUH #) -> writeArray# marr_apb 234# ipv_sUH s1_apc } -- RHS size: {terms: 18, types: 22, coercions: 0, joins: 0/0} indexThenWriteF indexThenWriteF = \ @ a_aq0 @ b_aq1 @ s_aq2 f_ape arr_apf marr_apg s1_aph -> writeArray# marr_apg 234# (case indexArray# arr_apf 123# of { (# ipv_sUK #) -> f_ape ipv_sUK }) s1_aph }}} I'd like the second function to generate code similar to the first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 06:57:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 06:57:55 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.f92dce048398d1015d845d19fb2a2af0@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): My current thoughts on this As I understand it, the Data instances can only be generated for concrete types. As such the index type is a red herring, as we need the Data instances for the indexed type. Effectively, we are tailoring the AST to be a number of concrete versions. This is the point of TTG. So making a Data instance per concrete version may be the best way to go. Plan B. So, we know we can do that with GHC 8.2, and do not want to complicate life in terms of cherry-picking in the interim. So, perhaps either put this work on hold, or do it in a long-running branch until such time as GHC 8.2 is the minimal bootstrap compiler. Yay 6 months cycles. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 10:42:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 10:42:05 -0000 Subject: [GHC] #14459: `make sdist-ghc` broken In-Reply-To: <042.28c91cc808d02e803cb2f4f0dc8cbb78@haskell.org> References: <042.28c91cc808d02e803cb2f4f0dc8cbb78@haskell.org> Message-ID: <057.fffc4729cd02439df74826a2256031dd@haskell.org> #14459: `make sdist-ghc` broken -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 11:04:01 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 11:04:01 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.d74f689d3c3250b7e6170c81e5f355f4@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by simonpj): Why does Plan B not work in 8.0.2? This works: {{{ {-# LANGUAGE TypeFamilies, GADTs, FlexibleInstances, StandaloneDeriving, DeriveDataTypeable #-} module Foo where import Data.Data data T a where MkT :: XT a -> a -> T a type family XT a type instance XT Bool = Int deriving instance Data (T Bool) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 11:09:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 11:09:05 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.86697e27ba80df9d2c90dcbf5d951bbd@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): But this does not {{{#!hs {-# LANGUAGE TypeFamilies, GADTs, FlexibleInstances, StandaloneDeriving, DeriveDataTypeable #-} module Foo where import Data.Data data T a where MkT :: XT a -> a -> T a type family XT a type instance XT Bool = Int type instance XT Char = Int deriving instance Data (T Bool) deriving instance Data (T Char) }}} And this models the situation in GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 11:17:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 11:17:49 -0000 Subject: [GHC] #14511: indexArray# getting poorly deferred In-Reply-To: <046.562c7ba6b9fb319f3069f981d147d69c@haskell.org> References: <046.562c7ba6b9fb319f3069f981d147d69c@haskell.org> Message-ID: <061.bdf144d8a0893d53d9f24ed192132cf7@haskell.org> #14511: indexArray# getting poorly deferred -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): Good point. Works fine in HEAD, as a result of this (post-8.2) patch {{{ commit 751996e90a964026a3f86853338f10c82db6b610 Author: Simon Peyton Jones Date: Fri Apr 7 17:10:07 2017 +0100 Kill off complications in CoreFVs ... * The code around floating case-expressions turned out to be very delicate, because can_fail primops (which we want to float inwards) can't be floated outwards; so we have to be careful never to float them too far. Note [Floating primops] has the details }}} I'll augment the Note to add your use-case. I'm not sure we can do much for 8.2; how important is it for you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 13:15:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 13:15:50 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDUwMDogQ29lcmNpb24gYXJ0aWZhY3Qg4oCY?= =?utf-8?q?cobox=E2=80=99_appears_in_error_message?= In-Reply-To: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> References: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> Message-ID: <066.0ce13244ded7647e1422fb2dcb1902a9@haskell.org> #14500: Coercion artifact ‘cobox’ appears in error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 RyanGlScott): Well, if the name "`cobox`" bothers you, you'll be happy to know that that name is no longer used in GHC HEAD (after 79ae03aa32c277ae93827519ed7738938e3e1572): {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs -fprint- explicit-coercions GHCi, version 8.3.20171118: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:14:39: error: • Couldn't match type ‘()’ with ‘TypeRep (a |> co)’ Expected type: TypeRep a Actual type: () • In the pattern: () In the pattern: Bloop' (HRefl :: N :~~: kk) () In the declaration for pattern synonym ‘SO’ | 14 | pattern SO <- Bloop' (HRefl::N:~~:kk) () | ^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 13:26:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 13:26:49 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.1929b3a2405dc60ac99c63c0e0fd7afd@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by Shayan-Najd): > So making a Data instance per concrete version may be the best way to go. Plan B. Regardless of the GHC version we use, the question is whether Plan B really fixes the build-time problem. Can we test it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 13:45:25 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 13:45:25 -0000 Subject: [GHC] #14495: Relocatable GHC In-Reply-To: <046.eee2e7ee2b5b793946317cc2c012eb42@haskell.org> References: <046.eee2e7ee2b5b793946317cc2c012eb42@haskell.org> Message-ID: <061.251d00fffface675965dfb8fe211a88e@haskell.org> #14495: Relocatable GHC -------------------------------------+------------------------------------- Reporter: bgamari | Owner: angerman Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Old description: > Moritz Angerman has recently been working on > [[https://github.com/snowleopard/hadrian/pull/445|enabling]] relocatable > builds of GHC in Hadrian. This will enable a user to extract a bindist > anywhere in their file system and expect it to work. Moreover, it should > simplify our installation procedure New description: Moritz Angerman has recently been working on [[https://github.com/snowleopard/hadrian/pull/445|enabling]] relocatable builds of GHC in Hadrian. This will enable a user to extract a bindist anywhere in their file system and expect it to work. Moreover, it should simplify our installation procedure. -- Comment (by bgamari): This will need two Cabal patches, * https://github.com/haskell/cabal/pull/4892 * https://github.com/haskell/cabal/pull/4874 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 13:55:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 13:55:28 -0000 Subject: [GHC] #14456: Windows runtime linker failure with icuuc In-Reply-To: <050.3b07902cfc2f558e6740649e9c204478@haskell.org> References: <050.3b07902cfc2f558e6740649e9c204478@haskell.org> Message-ID: <065.55b731962a1573af3a6535167fe73dd8@haskell.org> #14456: Windows runtime linker failure with icuuc -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * version: 8.2.1 => 8.2.2 Old description: > First, install `mingw-w64-x86_64-icu` (I'm using version 58.2-2): > > {{{ > $ pacman -S mingw-w64-x86_64-icu > }}} > > Now take this file: > > {{{#!hs > module Main where > > import Data.Int > import Foreign > > foreign import ccall "ucnv_getMaxCharSize_58" > c_ucnv_getMaxCharSize :: Ptr () -> IO Int8 > > main :: IO () > main = c_ucnv_getMaxCharSize nullPtr >>= print > }}} > > GHC is able to compile this successfully: > > {{{ > $ ghc -licuuc Bug2.hs > [1 of 1] Compiling Main ( Bug2.hs, Bug2.o ) > Linking Bug2.exe ... > }}} > > But GHCi is unable to accomplish the same thing: > > {{{ > $ runghc -licuuc Bug2.hs > ghc.exe: ^^ Could not load 'ucnv_getMaxCharSize_58', dependency > unresolved. See top entry above. > > Bug2.hs: > ByteCodeLink: can't find label > During interactive linking, GHCi couldn't find the following symbol: > ucnv_getMaxCharSize_58 > This may be due to you not asking GHCi to load extra object files, > archives or DLLs needed by your current session. Restart GHCi, > specifying > the missing library using the -L/path/to/object/dir and -lmissinglibname > flags, or simply by naming the relevant files on the GHCi command line. > Alternatively, this link failure might indicate a bug in GHCi. > If you suspect the latter, please send a bug report to: > glasgow-haskell-bugs at haskell.org > }}} > > Phyx- and I discussed this briefly on IRC. He suspected that the fact > that `C:\Windows\System32` now contains its own copy of `icuuc.dll` is > contributing to the issue. New description: First, install `mingw-w64-x86_64-icu` (I'm using version 58.2-2): {{{ $ pacman -S mingw-w64-x86_64-icu }}} Now take this file: {{{#!hs module Main where import Data.Int import Foreign import Foreign.C.String import Foreign.C.Types type UErrorCode = CInt u_ZERO_ERROR :: UErrorCode u_ZERO_ERROR = 0 foreign import ccall "ucnv_open_58" c_ucnv_open :: CString -> Ptr UErrorCode -> IO (Ptr ()) foreign import ccall "ucnv_getMaxCharSize_58" c_ucnv_getMaxCharSize :: Ptr () -> IO Int8 main :: IO () main = with u_ZERO_ERROR $ \status -> do conv <- c_ucnv_open nullPtr status c_ucnv_getMaxCharSize conv >>= print }}} GHC is able to compile this successfully: {{{ $ ghc -licuuc Bug2.hs [1 of 1] Compiling Main ( Bug2.hs, Bug2.o ) Linking Bug2.exe ... $ ./Bug2.exe 1 }}} But GHCi is unable to accomplish the same thing: {{{ $ runghc -licuuc Bug2.hs ghc.exe: | C:\Users\RyanGlScott\Documents\Hacking\Haskell\Bug2.o: unknown symbol `ucnv_open_58' Bug2.hs: }}} Phyx- and I discussed this briefly on IRC. He suspected that the fact that `C:\Windows\System32` now contains its own copy of `icuuc.dll` is contributing to the issue. -- Comment: Ah yes, `-llibicuuc` does indeed work with GHC HEAD. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 15:09:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 15:09:42 -0000 Subject: [GHC] #12159: Record-like GADTs with repeated fields (of same type) rejected In-Reply-To: <048.5dd46a690e4224728f1b88e3135dbfce@haskell.org> References: <048.5dd46a690e4224728f1b88e3135dbfce@haskell.org> Message-ID: <063.3b51ec77f8d596c5325f4657f0f66ea4@haskell.org> #12159: Record-like GADTs with repeated fields (of same type) rejected -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vagarenko): * cc: vagarenko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 15:22:03 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 15:22:03 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.608929ee4cbf6c4cc2f4942b0d472384@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK, I now know why this particular internal error occurs. To better explain what is going on, it's helpful to look at this program: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} data MyProxy (a :: k) = MyProxy f :: forall (a :: j). Int -> forall (b :: k). MyProxy a f _ = MyProxy @_ @b }}} GHC (rightfully) rejects this: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:9:19: error: Not in scope: type variable ‘b’ | 9 | f _ = MyProxy @_ @b | ^ }}} As one might expect, `b` is not brought into scope in the body of `f`—both in the current rules that GHC abides by, as well as in the proposed rules in #14288—since `b`'s quantification site is separated from the outermost `forall` by a visible argument. Now, what about this version of `f`? {{{#!hs f :: forall (a :: j). Int -> forall (b :: k). MyProxy a f _ = MyProxy @k @_ }}} GHC also rejects this, but this time it's a type error instead of a renamer error: {{{ GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:9:7: error: • Couldn't match type ‘k’ with ‘j’ ‘k’ is a rigid type variable bound by the type signature for: f :: forall j k (a :: j). Int -> forall (b :: k). MyProxy a at Bug.hs:8:1-55 ‘j’ is a rigid type variable bound by the type signature for: f :: forall j k (a :: j). Int -> forall (b :: k). MyProxy a at Bug.hs:8:1-55 Expected type: MyProxy a Actual type: MyProxy a • In the expression: MyProxy @k @_ In an equation for ‘f’: f _ = MyProxy @k @_ • Relevant bindings include f :: Int -> forall (b :: k). MyProxy a (bound at Bug.hs:9:1) | 9 | f _ = MyProxy @k @_ | ^^^^^^^^^^^^^ }}} This time, `k` passes the renamer, indicating that `k` is in fact brought into scope over the body of `f`! Why is `k` treated differently from `b`? As it turns out, it's due to the fact that `k` is implicitly quantified. Implicitly quantified type variables are always put at the front of function type signatures, as `-fprint-explicit-foralls` reveals: {{{ $ ghci -fprint-explicit-foralls -XPolyKinds -XRankNTypes GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> data MyProxy (a :: k) = MyProxy λ> f :: forall (a :: j). Int -> forall (b :: k). MyProxy a; f = undefined λ> :type +v f f :: forall j k (a :: j). Int -> forall (b :: k). MyProxy a }}} As a result, nested, implicitly quantified type variables are always brought into scope over the bodies of //functions//. See [http://git.haskell.org/ghc.git/blob/abdb5559b74af003a6d85f32695c034ff739f508:/compiler/hsSyn/HsTypes.hs#l837 hsWcScopedTvs and hsScopedTvs] for the code which is responsible for this behavior in the renamer. I put "//functions//" in italics since something different happens for pattern synonyms. Functions, when being typechecked, will bring all implicitly quantified type variables (nested or not) into scope, so you get a proper type error when typechecking the second iteration of `f`. Pattern synonyms, however, only bring the //outermost// implicitly quantified type variables into scope when being typechecked. (See [http://git.haskell.org/ghc.git/blob/abdb5559b74af003a6d85f32695c034ff739f508:/compiler/typecheck/TcPatSyn.hs#l167 this code in TcPatSyn].) As a result, there's a discrepancy between the treatment of pattern synonym signature type variables in the renamer (i.e., `hsScopedTvs`) and in the typechecker (the code in `TcPatSyn`), leading to the internal error reported above. Now that we've identified the cause of the issue, a question remains of how to fix it. I believe `TcPatSyn`'s strategy of only bringing the outermost implicitly quantified type variables into scope is the right one, and would think that adopting the same approach in the renamer (in `hsScopedTvs`) would be the right call. Even better, this wouldn't depend on a fix for #14288. There is a downside to this approach, however: there would be some obscure GHC programs that typecheck today that wouldn't after this change. For instance, this currently typechecks: {{{#!hs g :: forall (a :: j). Int -> forall (b :: k). MyProxy b g _ = MyProxy @k }}} But wouldn't after this proposed change, as `k` would no longer be in scope over the body of `g`. Is this an acceptable breakage? Or should we wait until a full-blown fix for #14288 is available (and put forth the fact that `g` would no longer typecheck as a downside in the GHC proposal accompanying #14288)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 16:47:49 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 16:47:49 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.3b8cdf8766a0674abec7bd40a7d9f6f8@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by bgamari): > I see. The goal is to simply see whether really Data instances are causing all performance issues. Sure, I think this is a perfectly reasonable experiment. I was just pointing out that we may eventually still need to provide some `Data` instances somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 17:13:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 17:13:48 -0000 Subject: [GHC] #14505: CircleCI only builds pushed heads In-Reply-To: <046.5fc442bf07e9d8a0060fa53efebf8332@haskell.org> References: <046.5fc442bf07e9d8a0060fa53efebf8332@haskell.org> Message-ID: <061.6bcc654588717a61c9fc518075c3c33c@haskell.org> #14505: CircleCI only builds pushed heads -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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): Indeed it appears that the CircleCI API [[https://circleci.com/docs/2.0/faq/#can-i-use-the-api-with-workflows|can not be used]] to start workflow builds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 17:40:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 17:40:50 -0000 Subject: [GHC] #14492: Tiered memory allocation restricts available memory In-Reply-To: <044.e21e37476590d999c81ca942af908658@haskell.org> References: <044.e21e37476590d999c81ca942af908658@haskell.org> Message-ID: <059.f743fe7f1d7f8a2380357e299c1fba83@haskell.org> #14492: Tiered memory allocation restricts available memory -------------------------------------+------------------------------------- Reporter: unode | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: memory ulimit Operating System: Linux | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4215 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Another option, as suggested by Jaffacake on Diff:D4215, would be to probe the limit. This test program {{{#!c #include #include #include #include void print_limit(const char* name, int resource) { struct rlimit lim; if (getrlimit(resource, &lim) != 0) { printf("%s: uh oh\n", name); exit(1); } printf("%s: cur: %d\n", name, lim.rlim_cur); printf("%s: max: %d\n", name, lim.rlim_max); } int main() { print_limit("AS", RLIMIT_AS); print_limit("DATA", RLIMIT_DATA); print_limit("RSS", RLIMIT_RSS); print_limit("STACK", RLIMIT_STACK); return 0; } }}} reveals that `ulimit -v` affects `RLIMIT_AS`, which can be probed with `getrlimit`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 18:18:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 18:18:30 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.9232f3be5c46128a7c67fb99b86050ef@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I suppose we wouldn't have to break anything for now if we went with another option: create a separate copy `hsScopedTvs` intended only for use with pattern synonyms and only apply the fix to that copy for now. That way, `g` would still continue to compile, as it would use the old codepath. Of course, we wouldn't want to maintain this `hsScopedTvs` split forever, but we can merge them back together when #14288 is implemented (where we have the liberty of changing the semantics of existing programs). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 19:27:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 19:27:17 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.27d531564ea9ccb194c08fb13785dbd4@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by ravi_n): If this ticket ends up making 8.4.1, what would that include? Just robustification or #12935 as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 19:40:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 19:40:32 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.9dc823854d0d1ee2e7553c57aac3d641@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 19:59:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 19:59:02 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.94add279e51a3f47213792b990693964@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by bgamari): I don't believe anyone is actively working on #12935 at the moment. Do let us know if you are interesting in working on it, ravi_n. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 20:12:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 20:12:32 -0000 Subject: [GHC] #14512: System-wide installed profile build cannot load libHSghc-prim.0.5.2.0.so Message-ID: <047.5a0900c5c72a8eef1106855d270e16d7@haskell.org> #14512: System-wide installed profile build cannot load libHSghc-prim.0.5.2.0.so -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Steps to reproduce: 1. Make a pristine git checkout 2. Follow the steps outlined in https://ghc.haskell.org/trac/ghc/wiki/Building/QuickStart, uncommenting the `BuildFlavour = prof` line in `build.mk`, to build and install ghc. 3. Check ghc version to verify that this ghc build is the one in `/usr/local/bin` 4. Try to compile the following `hello.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH main = putStrLn $(litE (stringL "Hello")) }}} It should fail with an error message similar to: {{{ : error: ghc: panic! (the 'impossible' happened) (GHC version 8.3.20171120 for x86_64-unknown-linux): Dynamic linker not initialised CallStack (from -prof): Linker.CAF () Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} and: {{{ : error: : can't load .so/.DLL for: libHSghc-prim-0.5.2.0.so (libHSghc-prim-0.5.2.0.so: cannot open shared object file: No such file or directory) }}} By contrast, the following do *not* trigger the error: - Building GHC without uncommenting the `BuildFlavour` line in `build.mk` - Compiling with the `inplace/bin/ghc-stage2` in the GHC source tree - Compiling a `hello.hs` that does not use TemplateHaskell Further system info: - Debian 9 - Cabal version 1.24 - GHC 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 21:47:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 21:47:08 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.bdc87cd20025a236255e1970b5243e82@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): Initial result: Compiling HsInstances with all the `GhcPs` etc variants takes around 90s and 1GB on my machine. GHC 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 22:40:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 22:40:39 -0000 Subject: [GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 In-Reply-To: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> References: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> Message-ID: <061.0584a78548399a2cab1410849a613700@haskell.org> #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ntc2): I'm observing an apparently **exponential run time performance regression** when combining GHC 8.2.1, `Data.Text.Lazy`, and `Text.RE.TDFA`. Here's my repo with simple test code illustrating the regression and timing stats: https://github.com/ntc2/ghc-8.2.1-regex-lazy- text-bug. In summary, for the problematic combination of GHC version and libraries, the run times are 3s, 10s, 22s, and 40s for counting regex matches in files with 10000, 20000, 30000, and 40000 lines, respectively. For all of the unproblematic combinations -- i.e. GHC 8.0.2, `String`, strict `Data.Text`, or building with profiling -- the run time is always about 1s! And this is a Heisenbug, in that the performance problem goes away if I build with profiling support! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 22 23:57:11 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Nov 2017 23:57:11 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.130c9e00fa18f853712f89fcf397ec09@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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 ravi_n): What's involved in fixing this? Is it just plugging away at a list of known sources of non-determinism or is it more complicated than that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 03:47:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 03:47:26 -0000 Subject: [GHC] #14510: GHC.ExecutionStack.showStackTrace broken In-Reply-To: <043.9685830b69e2246f2b96ccff19455218@haskell.org> References: <043.9685830b69e2246f2b96ccff19455218@haskell.org> Message-ID: <058.2fda19f4716c5626d6368a9329f24212@haskell.org> #14510: GHC.ExecutionStack.showStackTrace broken ---------------------------------+-------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 duog): bgamari was able to reproduce this, so it may well be a real bug. I spent some time today learning all about libdw, and I was able to determine what's going wrong, though not why. It happens at this "stack trace": [https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdw/dwarf_next_cfi.c;h=53fc369722e9685c04ca6f18ca683cf820b10338;hb=54ba4ce2973113d8f4315d4fc90e16a9b4476ea6#l55 libdw/dwarf_next_cfi.c:dwarf_next_cfi:55] [https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdw/fde.c;h=f5f6fbe14133b0cb36738e9c25a5cdfeaf3d9e8b;hb=54ba4ce2973113d8f4315d4fc90e16a9b4476ea6#l283 libdw/fde.c:__libdw_find_fde:283] [https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdw/dwarf_cfi_addrframe.c;h=44240279a957579b6c1d3469028e3d9df7da9411;hb=54ba4ce2973113d8f4315d4fc90e16a9b4476ea6#l42 libdw/dwarf_cfi_addrframe.c:dwarf_cfi_addrframe:42] [https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdwfl/frame_unwind.c;h=4dc9c43252fd0a232168ede0cbc6712da94cfaef;hb=54ba4ce2973113d8f4315d4fc90e16a9b4476ea6#l542 libdwfl/frame_unwind.c:handle_cfi:542] [https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdwfl/frame_unwind.c;h=4dc9c43252fd0a232168ede0cbc6712da94cfaef;hb=54ba4ce2973113d8f4315d4fc90e16a9b4476ea6#l722 libdwfl/frame_unwind.c:__libdwfl_frame_unwind:722] ... rts/libdw/libdwGetBacktrace `off + 4 >= data->d_size` is true. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 04:22:44 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 04:22:44 -0000 Subject: [GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 In-Reply-To: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> References: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> Message-ID: <061.e8279bcfb51be05af30c9337919fa793@haskell.org> #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): @ntc2, that is an interesting finding, but maybe worth a separate issue. Since you seem to have a nice setup to verify the problem, could you bisect which commit in GHC did this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 06:58:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 06:58:18 -0000 Subject: [GHC] #14513: +RTS -hT does not report about SmallArray objects Message-ID: <043.b1b38ed193abd9433ca67b5f216871b8@haskell.org> #14513: +RTS -hT does not report about SmallArray objects -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.2.1 System | Keywords: profiling | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- +RTS -hT seems to ignore SmallArray# objects. Also the combination of SmallArray# objects and -hT causes a segfault on ghc 7.10. To reproduce, save the following progam as smallarray.hs {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE BangPatterns #-} {-# LANGUAGE UnboxedTuples #-} import GHC.Exts import GHC.IO (IO(..), unIO) import Control.Concurrent import Control.Monad import System.Mem main :: IO () main = do forkIO $ forever $ performGC IO $ \s0 -> let !(# s01, msa #) = newSmallArray# 100# 'X' s0 !s02 = writeSmallArray# msa 4# 'Y' s01 !(# s1, sa #) = unsafeFreezeSmallArray# msa s02 !(# s2, () #) = unIO (threadDelay 5000000) s1 !(# v #) = indexSmallArray# sa 2# !(# s3, () #) = unIO (print v) s2 in (# s3, () #) }}} compile it, and run it like: {{{ ghc smallarray.hs -rtsopts -threaded ./samllarray +RTS -hT }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 06:58:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 06:58:35 -0000 Subject: [GHC] #14513: +RTS -hT does not report about SmallArray objects In-Reply-To: <043.b1b38ed193abd9433ca67b5f216871b8@haskell.org> References: <043.b1b38ed193abd9433ca67b5f216871b8@haskell.org> Message-ID: <058.0bab6cf05e6a7f66e09fd62764c03cdd@haskell.org> #14513: +RTS -hT does not report about SmallArray objects -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: profiling Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): I'm submitting a patch shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 07:35:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 07:35:28 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.8ac7cacddfd1f27fb4c347e7f3304cdd@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): And here is an interesting result from validation with my branch `wip/ttg6-unrevert-2017-11-22` {{{ =====> haddock.base(normal) 1 of 3 [0, 0, 0] bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected haddock.base(normal) bytes allocated: 19694554424 +/-5% Lower bound haddock.base(normal) bytes allocated: 18709826702 Upper bound haddock.base(normal) bytes allocated: 20679282146 Actual haddock.base(normal) bytes allocated: 17315438736 Deviation haddock.base(normal) bytes allocated: -12.1 % *** unexpected stat test failure for haddock.base(normal) =====> haddock.Cabal(normal) 2 of 3 [0, 0, 0] bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected haddock.Cabal(normal) bytes allocated: 20104611952 +/-5% Lower bound haddock.Cabal(normal) bytes allocated: 19099381354 Upper bound haddock.Cabal(normal) bytes allocated: 21109842550 Actual haddock.Cabal(normal) bytes allocated: 18233466752 Deviation haddock.Cabal(normal) bytes allocated: -9.3 % *** unexpected stat test failure for haddock.Cabal(normal) =====> haddock.compiler(normal) 3 of 3 [0, 0, 0] bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected haddock.compiler(normal) bytes allocated: 102142130576 +/-10% Lower bound haddock.compiler(normal) bytes allocated: 91927917518 Upper bound haddock.compiler(normal) bytes allocated: 112356343634 Actual haddock.compiler(normal) bytes allocated: 51327433048 Deviation haddock.compiler(normal) bytes allocated: -49.7 % *** unexpected stat test failure for haddock.compiler(normal) Unexpected results from: TEST="haddock.Cabal haddock.base haddock.compiler" SUMMARY for test run started at Thu Nov 23 07:28:46 2017 UTC 0:00:00 spent to go through 3 total tests, which gave rise to 3 test cases, of which 0 were skipped 0 had missing libraries 0 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 3 unexpected stat failures Unexpected stat failures: perf/haddock/haddock.base.run haddock.base [stat too good] (normal) perf/haddock/haddock.Cabal.run haddock.Cabal [stat too good] (normal) perf/haddock/haddock.compiler.run haddock.compiler [stat too good] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 07:44:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 07:44:09 -0000 Subject: [GHC] #14513: +RTS -hT does not report about SmallArray objects In-Reply-To: <043.b1b38ed193abd9433ca67b5f216871b8@haskell.org> References: <043.b1b38ed193abd9433ca67b5f216871b8@haskell.org> Message-ID: <058.3d10cd082649b7a7339647bfe9e1ce83@haskell.org> #14513: +RTS -hT does not report about SmallArray objects -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: profiling Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4226 Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * status: new => patch * differential: => Phab:D4226 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 11:30:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 11:30:40 -0000 Subject: [GHC] #14514: Higher-Rank Kinds work in ADT but not GADT Message-ID: <051.b76142fd8282a689e3ab27ed27c38d69@haskell.org> #14514: Higher-Rank Kinds work in ADT but not GADT -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Following code from [https://github.com/goldfirere/triptych/blob/2e21a6be4419873c77a02c9a198379c76947b94c/extensibility/Extensible6.hs Richard's 2016 Haskell Implementors' Workshop talk] (/ [https://arxiv.org/abs/1610.04799 Trees That Grow]) works just fine {{{#!hs {-# Language RankNTypes, KindSignatures, DataKinds, TypeFamilyDependencies, TypeInType #-} import Data.Kind data TagTag = ETagTag | PTagTag data ETag = VarTag data PTag = VarPTag type family Tag (ttag::TagTag) = (res :: Type) | res -> ttag where Tag ETagTag = ETag Tag PTagTag = PTag type WithAnyTag = forall tag. Tag tag -> Type -- data Exp (ext::WithAnyTag) where -- Var :: ext VarTag -> Exp ext data Exp (ext::WithAnyTag) = Var (ext VarTag) }}} but replace `data Exp` with its commented-out GADT brethren and it stops working {{{ $ ghci -ignore-dot-ghci Weird.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Weird.hs, interpreted ) Weird.hs:17:28: error: • Expected kind ‘WithAnyTag’, but ‘ext1’ has kind ‘ETag -> *’ • In the first argument of ‘Exp’, namely ‘ext’ In the type ‘Exp ext’ In the definition of data constructor ‘Var’ | 17 | Var :: ext VarTag -> Exp ext | ^^^ Failed, 0 modules loaded. Prelude> }}} The type synonym can be inlined, makes no difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 11:47:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 11:47:45 -0000 Subject: [GHC] #14514: Higher-Rank Kinds work in ADT but not GADT In-Reply-To: <051.b76142fd8282a689e3ab27ed27c38d69@haskell.org> References: <051.b76142fd8282a689e3ab27ed27c38d69@haskell.org> Message-ID: <066.150b362e9cc48b75970aaea3f1e29649@haskell.org> #14514: Higher-Rank Kinds work in ADT but not GADT -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Iceland_jack): I suppose the answer is that [https://ghc.haskell.org/trac/ghc/ticket/14352#comment:1 “GHC never infers a higher-rank kind”]. The correct way of writing this is explicitly quantifying over the kind of `ext` when writing it as a GADT (as is done here: [https://github.com/goldfirere/dependent-db/blob/master/Basics.hs#L134 TypeRepX]) {{{#!hs data Exp :: WithAnyTag -> Type where Var :: forall (ext::WithAnyTag). ext VarTag -> Exp ext -- .. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 12:44:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 12:44:35 -0000 Subject: [GHC] #14515: "Same" higher-rank kind synonyms behave differently Message-ID: <051.ddfbd3b154f112afe25d8aace589b1bc@haskell.org> #14515: "Same" higher-rank kind synonyms behave differently -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 you know type-level `forall`s don't float, so we may want to write `HRefl`'s kind {{{#!hs -- Different from -- HREFL :: forall k1 k2. k1 -> k2 -> Type -- data HREFL :: forall k1. k1 -> (forall k2. k2 -> Type) where HREFL :: HREFL a a }}} Let us capture `forall k2. k2 -> ..` with a kind synonym {{{#!hs type HRank2 ty = forall k2. k2 -> ty data HREFL :: forall k. k -> HRank2 Type where HREFL :: HREFL a a }}} Works fine. Phew. Let's do the same for `forall k1. k1 -> ..` {{{#!hs type HRank1 ty = forall k1. k1 -> ty type HRank2 ty = forall k2. k2 -> ty data HREFL :: HRank1 (HRank2 Type) where HREFL :: HREFL a a }}} Works fine. Phew. “Didn't you just define the same kind synonym twice?” The funny thing is that this fails to compile when they coincide! {{{#!hs data HREFL :: HRank1 (HRank1 Type) -- FAILS data HREFL :: HRank1 (HRank2 Type) -- OK data HREFL :: HRank2 (HRank1 Type) -- OK data HREFL :: HRank2 (HRank2 Type) -- FAILS }}} {{{ $ ghci -ignore-dot-ghci /tmp/Weird.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Weird.hs, interpreted ) /tmp/Weird.hs:8:1: error: • These kind and type variables: (b :: k2) k2 (d :: k2) are out of dependency order. Perhaps try this ordering: k2 (b :: k2) (d :: k2) • In the data type declaration for ‘HREFL’ | 8 | data HREFL :: HRank2 (HRank2 Type) | ^^^^^^^^^^ Failed, 0 modules loaded. Prelude> }}} Same happens defining `HRank2` in terms of `HRank1` {{{#!hs type HRank1 ty = forall k1. k1 -> ty type HRank2 ty = HRank1 ty }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 12:53:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 12:53:58 -0000 Subject: [GHC] #14516: getGCStats was broken in 8.2 Message-ID: <048.f2f53ed169f1f3d9dc0f869cb0501a1f@haskell.org> #14516: getGCStats was broken in 8.2 -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.1 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: -------------------------------------+------------------------------------- The {{{getGCStats}}} function from {{{GHC.Stats}}} defined [http://hackage.haskell.org/package/base-4.10.0.0/docs/GHC-Stats.html#g:2 here] expects the {{{numGCs}}} field to be an {{{Int64}}}, but in the new {{{RTSStats}}} API, it's a {{{Word32}}}, so the function inside is no longer correct: {{{ getGCStats = do ... allocaBytes ((232)) $ \p -> do {-# LINE 284 "GHC/Stats.hsc" #-} getRTSStats_ p bytesAllocated <- ((\hsc_ptr -> peekByteOff hsc_ptr 8)) p {-# LINE 286 "GHC/Stats.hsc" #-} numGcs <- ((\hsc_ptr -> peekByteOff hsc_ptr 0)) p {-# LINE 287 "GHC/Stats.hsc" #-} numByteUsageSamples <- ((\hsc_ptr -> peekByteOff hsc_ptr 4)) p }}} The {{{numGcs}}} line peeks off 8 bytes instead of 4, and so it leads to packages like my {{{weigh}}} package claiming that you've done "4,294,967,299" garbage collections. I've updated {{{weigh}}} to use the new API with some CPP {{{#if}}}'s. Given that the new API changes pretty much everything, both names and types (it took a couple hours to make weigh support the old and the new one), and that the old "compatibility" API is returning bad results, honestly I wouldn't have minded if the old API was just removed in 8.2. Leaving it up to you whether this should be fixed in an 8.2.3 bugfix release or just leave it to be removed in 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 14:06:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 14:06:07 -0000 Subject: [GHC] #14483: getExecutablePath from System.Environment in base should follow symlinks properly. In-Reply-To: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> References: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> Message-ID: <062.629f32aacdf560a43b01a5d9d8fb494f@haskell.org> #14483: getExecutablePath from System.Environment in base should follow symlinks properly. -------------------------------------+------------------------------------- Reporter: angerman | Owner: alpmestan Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.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): D4227 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: new => patch * differential: => D4227 Comment: I have a patch that improves the windows implementation of `getExecutablePath` so that it follows symlinks at https://phabricator.haskell.org/D4227 -- feedback welcome. This however does not change ghc, ghc-pkg and hsc2hs to use `getExecutablePath` (instead of the current duplicated code that does something equivalent). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 14:19:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 14:19:03 -0000 Subject: [GHC] #14514: Higher-Rank Kinds work in ADT but not GADT In-Reply-To: <051.b76142fd8282a689e3ab27ed27c38d69@haskell.org> References: <051.b76142fd8282a689e3ab27ed27c38d69@haskell.org> Message-ID: <066.fa14eeb4659f139d093414070ef0ba94@haskell.org> #14514: Higher-Rank Kinds work in ADT but not GADT -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 RyanGlScott): * status: new => closed * resolution: => invalid Comment: Replying to [comment:1 Iceland_jack]: > Please close is that is the case You got it. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 14:20:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 14:20:01 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDUwMDogQ29lcmNpb24gYXJ0aWZhY3Qg4oCY?= =?utf-8?q?cobox=E2=80=99_appears_in_error_message?= In-Reply-To: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> References: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> Message-ID: <066.8c2453493721731233071ac0b940dda4@haskell.org> #14500: Coercion artifact ‘cobox’ appears in error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 RyanGlScott): * status: new => closed * resolution: => invalid Comment: Closing, as this is working as advertised. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 14:36:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 14:36:10 -0000 Subject: [GHC] #14514: Higher-Rank Kinds work in ADT but not GADT In-Reply-To: <051.b76142fd8282a689e3ab27ed27c38d69@haskell.org> References: <051.b76142fd8282a689e3ab27ed27c38d69@haskell.org> Message-ID: <066.716f5f700b1124ad3bdf68616b43c10e@haskell.org> #14514: Higher-Rank Kinds work in ADT but not GADT -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Great, could GHC detect that `ETag -> Type` is an instance (don't know the right terminology) of `WithAnyTag` and propose quantifying over it? {{{ • Expected kind ‘WithAnyTag’, but ‘ext1’ has kind ‘ETag -> *’ • In the first argument of ‘Exp’, namely ‘ext’ In the type ‘Exp ext’ In the definition of data constructor ‘Var’ | 17 | Var :: ext VarTag -> Exp ext | ^^^ • Try quantifying over `AnyTag` | 17 | Var :: forall (ext::AnyTag). ext VarTag -> Exp ext | }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 14:37:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 14:37:00 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDUwMDogQ29lcmNpb24gYXJ0aWZhY3Qg4oCY?= =?utf-8?q?cobox=E2=80=99_appears_in_error_message?= In-Reply-To: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> References: <051.78e6de81f0e3a6f4e6f4a864e580a87b@haskell.org> Message-ID: <066.ea909bb85ea95570c1b8679bcfee5883@haskell.org> #14500: Coercion artifact ‘cobox’ appears in error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Yes, it was confusion on my part -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 14:48:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 14:48:28 -0000 Subject: [GHC] #14515: "Same" higher-rank kind synonyms behave differently In-Reply-To: <051.ddfbd3b154f112afe25d8aace589b1bc@haskell.org> References: <051.ddfbd3b154f112afe25d8aace589b1bc@haskell.org> Message-ID: <066.dfb1e2854ba1196eab9dd625fba8a2fc@haskell.org> #14515: "Same" higher-rank kind synonyms behave differently -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType 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 RyanGlScott): * keywords: => TypeInType * failure: None/Unknown => GHC rejects valid program * component: Compiler => Compiler (Type checker) Comment: For the sake of convenience, here's all of the various combinations in one file: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind type HRank1 ty = forall k1. k1 -> ty type HRank2 ty = forall k2. k2 -> ty data HREFL11 :: HRank1 (HRank1 Type) where HREFL11 :: HREFL11 a a data HREFL12 :: HRank1 (HRank2 Type) where HREFL12 :: HREFL12 a a data HREFL21 :: HRank2 (HRank1 Type) where HREFL21 :: HREFL21 a a data HREFL22 :: HRank2 (HRank2 Type) where HREFL22 :: HREFL22 a a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 15:01:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 15:01:25 -0000 Subject: [GHC] #14515: "Same" higher-rank kind synonyms behave differently In-Reply-To: <051.ddfbd3b154f112afe25d8aace589b1bc@haskell.org> References: <051.ddfbd3b154f112afe25d8aace589b1bc@haskell.org> Message-ID: <066.0620b9cb2cce0768e8914fd5b432b6d5@haskell.org> #14515: "Same" higher-rank kind synonyms behave differently -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType 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 Iceland_jack): The constructor isn't necessary to trigger it {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind type HRank1 ty = forall k1. k1 -> ty type HRank2 ty = forall k2. k2 -> ty data HREFL11 :: HRank1 (HRank1 Type) -- FAILS data HREFL12 :: HRank1 (HRank2 Type) data HREFL21 :: HRank2 (HRank1 Type) data HREFL22 :: HRank2 (HRank2 Type) -- FAILS }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 15:23:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 15:23:18 -0000 Subject: [GHC] #14516: getGCStats was broken in 8.2 In-Reply-To: <048.f2f53ed169f1f3d9dc0f869cb0501a1f@haskell.org> References: <048.f2f53ed169f1f3d9dc0f869cb0501a1f@haskell.org> Message-ID: <063.baf71f087937826785cb47e5ba2bf646@haskell.org> #14516: getGCStats was broken in 8.2 -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: libraries/base | Version: 8.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 bgamari): * milestone: => 8.2.3 Comment: It's unclear whether there will be a 8.2.3, but if there is one I will consider ripping out the interface. Thanks for raising this, Chris! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 17:13:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 17:13:56 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.2ef48c9f8f78e2a1e3c0bcb5956d7fee@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by Shayan-Najd): This sounds good!Thanks. So in short, `wip/ttg6-unrevert-2017-11-22` is a branch where (a) the three TTG patches are applied, (b) the `Data` instances are gathered together, and (c) Plan B is used. And, the experiment shows less memory allocation when building GHC? What about the overall build-time performance? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 17:59:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 17:59:01 -0000 Subject: [GHC] #14513: +RTS -hT does not report about SmallArray objects In-Reply-To: <043.b1b38ed193abd9433ca67b5f216871b8@haskell.org> References: <043.b1b38ed193abd9433ca67b5f216871b8@haskell.org> Message-ID: <058.df77fcf1b62b5191a043a24234b37c8b@haskell.org> #14513: +RTS -hT does not report about SmallArray objects -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 Resolution: | Keywords: profiling Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4226 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5e356276efffa40e82c89628fbdf1a38ca489216/ghc" 5e356276/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5e356276efffa40e82c89628fbdf1a38ca489216" rts/Printer: add closure name entries for small arrays (Fixes #14513) Test Plan: ./validate Reviewers: bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14513 Differential Revision: https://phabricator.haskell.org/D4226 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 18:19:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 18:19:09 -0000 Subject: [GHC] #14513: +RTS -hT does not report about SmallArray objects In-Reply-To: <043.b1b38ed193abd9433ca67b5f216871b8@haskell.org> References: <043.b1b38ed193abd9433ca67b5f216871b8@haskell.org> Message-ID: <058.681b43da69a061bf13aa7ce3cc5ad158@haskell.org> #14513: +RTS -hT does not report about SmallArray objects -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.1 Resolution: fixed | Keywords: profiling Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4226 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 19:29:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 19:29:55 -0000 Subject: [GHC] #14517: ghc: panic! (the 'impossible' happened) Message-ID: <044.c79635b93e3a22f86d7aabb95e3d5897@haskell.org> #14517: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: KtorZ | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Apparently not so impossible. I am just filling a bug following the advice of GHC. Here's the error message coming out of GHC {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] liftIO_a2jc :: t_a2jb[tau:1] (CHoleCan: liftIO) [W] handleMsg_a2k6 :: t_a2k5[tau:1] (CHoleCan: handleMsg) [W] expectTimeout_a2kb :: t_a2ka[tau:1] (CHoleCan: expectTimeout) [W] sendMsg_a2v9 :: t_a2v8[tau:1] (CHoleCan: sendMsg) [W] tick_a2vc :: t_a2vb[tau:1] (CHoleCan: tick)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} And here the corresponding code that leads to this compilation error: {{{ module Main where import Control.Distributed.Process (NodeId (..), Process) import Control.Monad (forever) import Data.IORef (IORef, newIORef) type Clock = Int emitRandomNumbers :: [NodeId] -> Process () emitRandomNumbers nodes = do clock <- liftIO $ newIORef (0 :: Clock) forever $ do msg <- handleMsg <$> expectTimeout 0 sendMsg <$> tick }}} I am compiling on with GHC 8.0.2 on Ubuntu 16.04, here are a list of the install dependencies: {{{ array 0.5.1.1 base 4.9.1.0 binary 0.8.3.0 bytestring 0.10.8.1 containers 0.5.7.1 data-accessor 0.2.2.7 deepseq 1.4.2.0 distributed-process 0.7.3 distributed-static 0.3.8 exceptions 0.8.3 getting-started 0.1.0.0 ghc-boot-th 8.0.2 ghc-prim 0.5.0.0 hashable 1.2.6.1 integer-gmp 1.0.0.1 mtl 2.2.1 network 2.6.3.2 network-transport 0.4.4.0 network-transport-tcp 0.5.1 pretty 1.1.3.3 random 1.1 rank1dynamic 0.3.3.0 rts 1.0 stm 2.4.4.1 syb 0.7 template-haskell 2.11.1.0 text 1.2.2.2 time 1.6.0.1 transformers 0.5.2.0 transformers-compat 0.5.1.4 unix 2.7.2.1 }}} Let me know should you need any additional informations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 20:43:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 20:43:46 -0000 Subject: [GHC] #14517: ghc: panic! (the 'impossible' happened) In-Reply-To: <044.c79635b93e3a22f86d7aabb95e3d5897@haskell.org> References: <044.c79635b93e3a22f86d7aabb95e3d5897@haskell.org> Message-ID: <059.77c490db6a31c6728cfcc15f0cbd4724@haskell.org> #14517: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: KtorZ | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13106 Comment: Thanks for the bug report. This is a duplicate of #13106, and has been fixed in GHC 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 21:35:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 21:35:47 -0000 Subject: [GHC] #14510: GHC.ExecutionStack.showStackTrace broken In-Reply-To: <043.9685830b69e2246f2b96ccff19455218@haskell.org> References: <043.9685830b69e2246f2b96ccff19455218@haskell.org> Message-ID: <058.03e9d32796b33238e5dff5255d4f47fc@haskell.org> #14510: GHC.ExecutionStack.showStackTrace broken ---------------------------------+-------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | ---------------------------------+-------------------------------------- Changes (by bollu): * cc: bollu (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 23 22:53:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Nov 2017 22:53:19 -0000 Subject: [GHC] #14518: GHC panic when trying to install Stack-1.5.1 with Cabal. Message-ID: <046.8cc838f5db9c89e4f01bf5d374aa733b@haskell.org> #14518: GHC panic when trying to install Stack-1.5.1 with Cabal. -------------------------------------+------------------------------------- Reporter: adgalad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 7.10.4 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- cabal: Entering directory '/var/folders/6v/r_hy_wrs5bbfnb4qc4ycxfpw0000gn/T/cabal- tmp-2256/stack-1.5.1' [1 of 1] Compiling Main ( /var/folders/6v/r_hy_wrs5bbfnb4qc4ycxfpw0000gn/T/cabal- tmp-2256/stack-1.5.1/dist/setup/setup.hs, /var/folders/6v/r_hy_wrs5bbfnb4qc4ycxfpw0000gn/T/cabal- tmp-2256/stack-1.5.1/dist/setup/Main.o ) Linking /var/folders/6v/r_hy_wrs5bbfnb4qc4ycxfpw0000gn/T/cabal- tmp-2256/stack-1.5.1/dist/setup/setup ... Configuring stack-1.5.1... Building stack-1.5.1... Preprocessing library stack-1.5.1... [ 1 of 128] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, dist/build/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 128] Compiling Hackage.Security.Client.Repository.HttpLib.HttpClient ( src/Hackage/Security/Client/Repository/HttpLib/HttpClient.hs, dist/build/Hackage/Security/Client/Repository/HttpLib/HttpClient.o ) [ 3 of 128] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, dist/build/Stack/Ghci/Script.o ) [ 4 of 128] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, dist/build/Stack/FileWatch.o ) [ 5 of 128] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, dist/build/System/Process/PagerEditor.o ) [ 6 of 128] Compiling System.Process.Log ( src/System/Process/Log.hs, dist/build/System/Process/Log.o ) [ 7 of 128] Compiling Stack.Types.StringError ( src/Stack/Types/StringError.hs, dist/build/Stack/Types/StringError.o ) [ 8 of 128] Compiling Paths_stack ( dist/build/autogen/Paths_stack.hs, dist/build/Paths_stack.o ) [ 9 of 128] Compiling Path.Find ( src/Path/Find.hs, dist/build/Path/Find.o ) [ 10 of 128] Compiling Path.Extra ( src/Path/Extra.hs, dist/build/Path/Extra.o ) [ 11 of 128] Compiling System.Process.Read ( src/System/Process/Read.hs, dist/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/6v/r_hy_wrs5bbfnb4qc4ycxfpw0000gn/T/ghc2807_0/libghc_69.dylib, 5): no suitable image found. Did find: /var/folders/6v/r_hy_wrs5bbfnb4qc4ycxfpw0000gn/T/ghc2807_0/libghc_69.dylib: malformed mach-o: load commands size (41168) > 32768 /var/folders/6v/r_hy_wrs5bbfnb4qc4ycxfpw0000gn/T/ghc2807_0/libghc_69.dylib: stat() failed with errno=25 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Leaving directory '/var/folders/6v/r_hy_wrs5bbfnb4qc4ycxfpw0000gn/T /cabal-tmp-2256/stack-1.5.1' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 02:57:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 02:57:37 -0000 Subject: [GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 In-Reply-To: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> References: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> Message-ID: <061.622843b11093404a50954d1588394e18@haskell.org> #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ntc2): * cc: ntc2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 02:59:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 02:59:34 -0000 Subject: [GHC] #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 In-Reply-To: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> References: <046.b7de3eed99bc2dfd75756f4f73799d3c@haskell.org> Message-ID: <061.90775abd34fd32876b88a954478c2f97@haskell.org> #13745: Investigate compile-time regressions in regex-tdfa-1.2.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ntc2): @nomeata, I'll create a separate issue and try the bisection. Never done Git bisection before, but found a GHC docs page here: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Bisection. (also, I thought commenting added me to the CC list, but apparently not) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 04:04:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 04:04:17 -0000 Subject: [GHC] #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA Message-ID: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: https://github.com/ntc2/ghc-8.2.1 | -regex-lazy-text-bug | Blocking: | Related Tickets: 13745 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using `Text.RE.TDFA` from the regex-tdfa package on GHC 8.2 to match trivial regexes against `Data.Text.Lazy` strings, I see **exponential runtime**. On GHC 8.0, or using `Data.Text` strict strings or `String` strings, the runtime is as expected. Here's my repo with simple test code illustrating the regression and timing stats: https://github.com/ntc2/ghc-8.2.1-regex-lazy-text-bug. In summary, for the problematic combination of GHC version and libraries, the run times are 3s, 10s, 22s, and 40s for counting regex matches in files with 10000, 20000, 30000, and 40000 lines, respectively. For all of the unproblematic combinations -- i.e. GHC 8.0.2, `String`, strict `Data.Text`, or building with profiling -- the run time is always about 1s! And **this is a Heisenbug**, in that the performance problem goes away if I build with profiling support! There is the separate Issue #13745 about **compile-time regressions** in GHC 8.2 + the regex-tdfa package, that [https://ghc.haskell.org/trac/ghc/ticket/13745#comment:18 I commented on]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 04:05:10 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 04:05:10 -0000 Subject: [GHC] #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA In-Reply-To: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> References: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> Message-ID: <058.f0944c0b2f6d6e32ceb4f7cc79569442@haskell.org> #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | https://github.com/ntc2/ghc-8.2.1 | -regex-lazy-text-bug Blocked By: | Blocking: Related Tickets: 13745 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ntc2): * Attachment "Main.hs" added. Test code that exhibits exponential runtime regression -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 04:06:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 04:06:04 -0000 Subject: [GHC] #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA In-Reply-To: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> References: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> Message-ID: <058.07734377b7f84dd744b2938d754ab8ec@haskell.org> #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | https://github.com/ntc2/ghc-8.2.1 | -regex-lazy-text-bug Blocked By: | Blocking: Related Tickets: 13745 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ntc2): * Attachment "defs-30000.txt" added. Input file for test program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 04:07:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 04:07:22 -0000 Subject: [GHC] #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA In-Reply-To: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> References: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> Message-ID: <058.3eaee832d42e95f0108622f3c3b6a48b@haskell.org> #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | https://github.com/ntc2/ghc-8.2.1 | -regex-lazy-text-bug Blocked By: | Blocking: Related Tickets: 13745 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ntc2): As suggested by @nomeata, I'm going to try bisecting GHC between 8.0.2 and 8.2.0 to discover when the performance regression was introduced. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 05:42:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 05:42:55 -0000 Subject: [GHC] #14520: GHC panic (TypeInType) Message-ID: <051.e31c3c48e10a5a880c2a9982e47d2da1@haskell.org> #14520: GHC panic (TypeInType) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language TypeInType, TypeFamilies, TypeOperators #-} import Data.Kind type a ~>> b = (a, b) -> Type data family Sing (a::k) type family (·) (f::a~>>b) (x::a)::b class PCategory kat where type Id ::kat·a·a type Comp::kat·b·c -> kat·a·b -> kat·a·c class SCategory kat where sId :: Sing a -> Sing (Id::kat a a) sComp :: Sing f -> Sing g -> Sing (Comp f g) }}} triggers a panic {{{ $ ghci -ignore-dot-ghci Bug.hs GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20171122 for x86_64-unknown-linux): piResultTy k_a1KI[tau:1] a_a1vb[sk:1] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1147:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:951:35 in ghc:Type piResultTy, called at compiler/types/Type.hs:2309:34 in ghc:Type typeKind, called at compiler/types/Type.hs:2309:46 in ghc:Type typeKind, called at compiler/typecheck/TcType.hs:1706:11 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 06:27:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 06:27:35 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.7e78b88aa2e67491b74dc98bafb7e931@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): Gipedia takes the build time from 2063 to 2271 seconds with this approach. A 10% change. https://perf.haskell.org/ghc/#compare/abdb5559b74af003a6d85f32695c034ff739f508/6a313b17191e77723368b380f51656faccdd8da2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 07:53:59 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 07:53:59 -0000 Subject: [GHC] #14521: Infinite loop at runtime when a given function is not marked INLINE Message-ID: <050.17f0ae18f3e58888a2116da899248456@haskell.org> #14521: Infinite loop at runtime when a given function is not marked INLINE -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, in https://github.com/OlivierSohn/hamazed/issues/1 I describe the following issue: When compiling on OSX with optimizations (`stack clean && stack build` with resolver `lts-9.12` (ghc 8.0.2)), the program loops infinitely (400% CPU, and execution is blocked) when an animation is triggered, if the function `Animation.animate'` is not inlined. The bug is visible at this commit : https://github.com/OlivierSohn/hamazed/commit/9f25223ef0502f91cd9633654bdb172f714c3920 (to reproduce, shoot at a number in the game) The fix is the commit that follows : https://github.com/OlivierSohn/hamazed/commit/597619bb14974d2bbacfb284a9e276a7cf2d2f52 stack version: `1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 hpack-0.15.0` Could this be a compiler bug? The code is available at https://github.com/OlivierSohn/hamazed I could try to create another program that reproduces the issue more easily (without having to play the game), just let me know if you need it. Thank you, Olivier -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 10:38:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 10:38:21 -0000 Subject: [GHC] #14522: GHC recompilation checker doesn't take account of deprecated pragmas Message-ID: <051.f11ced4a827db71935da5af834a388bc@haskell.org> #14522: GHC recompilation checker doesn't take account of deprecated pragmas -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given the sources: {{{#!hs -- A.hs -------------------- module A -- {-# DEPRECATED "bad" #-} where a = 1 }}} {{{#!hs -- B.hs -------------------- module B where import A }}} I get the interactions: {{{ $ ghc B [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling B ( B.hs, B.o ) $ manually edit A.hs to uncomment the deprecated line $ ghc B [1 of 2] Compiling A ( A.hs, A.o ) $ touch B.hs $ ghc B [2 of 2] Compiling B ( B.hs, B.o ) B.hs:2:1: warning: [-Wdeprecations] Module `A' is deprecated: bad | 2 | import A | ^^^^^^^^ }}} Observe that after editing the deprecated pragma in {{{A.hs}}} GHC didn't recompile {{{B.hs}}}, meaning that the warning only appeared after I touch'd {{{B.hs}}}. Turning on {{{-Werror}}} turns the problem from one of incorrectly missing warnings to one of incorrect compilation results. I was also got the same results when adding a deprecated pragma to an individual function. My guess is whatever {{{.hi}}} hash you take for recompilation checking should include deprecated pragmas. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 10:51:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 10:51:33 -0000 Subject: [GHC] #14483: getExecutablePath from System.Environment in base should follow symlinks properly. In-Reply-To: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> References: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> Message-ID: <062.8d12684e7e0653e8898e7efd346b1ead@haskell.org> #14483: getExecutablePath from System.Environment in base should follow symlinks properly. -------------------------------------+------------------------------------- Reporter: angerman | Owner: alpmestan Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.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): D4227 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): And here is a patch in which I switch ghc/ghc-pkg to using `getExecutablePath` when built with a recent enough `base`: https://phabricator.haskell.org/D4229 Eventually, in a few major versions, we'll be able to get rid of the `base < 4.11` code path and simply use `getExecutablePath`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 12:07:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 12:07:36 -0000 Subject: [GHC] #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field (was: Infinite loop at runtime when a given function is not marked INLINE) In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.5e6df7220095b8522224085aaa61d315@haskell.org> #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | 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 OlivierSohn: Old description: > Hello, > > in https://github.com/OlivierSohn/hamazed/issues/1 I describe the > following issue: > > When compiling on OSX with optimizations (`stack clean && stack build` > with resolver `lts-9.12` (ghc 8.0.2)), the program loops infinitely (400% > CPU, and execution is blocked) when an animation is triggered, if the > function `Animation.animate'` is not inlined. > > The bug is visible at this commit : > https://github.com/OlivierSohn/hamazed/commit/9f25223ef0502f91cd9633654bdb172f714c3920 > (to reproduce, shoot at a number in the game) > > The fix is the commit that follows : > https://github.com/OlivierSohn/hamazed/commit/597619bb14974d2bbacfb284a9e276a7cf2d2f52 > > stack version: `1.3.2, Git revision > 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 > hpack-0.15.0` > > Could this be a compiler bug? > > The code is available at https://github.com/OlivierSohn/hamazed > > I could try to create another program that reproduces the issue more > easily (without having to play the game), just let me know if you need > it. > > Thank you, > Olivier New description: Hello, in https://github.com/OlivierSohn/hamazed/issues/1 I describe the following issue: When compiling on OSX with optimizations (`stack clean && stack build` with resolver `lts-9.12` (ghc 8.0.2)), the program loops infinitely (400% CPU, and execution is blocked) when an animation is triggered, if the function `Animation.animate'` is not inlined. The bug is visible at this commit : https://github.com/OlivierSohn/hamazed/commit/9f25223ef0502f91cd9633654bdb172f714c3920 (to reproduce, shoot at a number in the game) I originally fixed this behaviour by declaring the function that consumes the Animator record INLINE : https://github.com/OlivierSohn/hamazed/commit/597619bb14974d2bbacfb284a9e276a7cf2d2f52 And later, I found that another way to fix the behaviour is to remove the strict annotation on the fields of the record "Animator", ie changing ` data Animator a = Animator { _animatorPure :: !(Iteration -> (Coords -> Location) -> Tree -> Tree) , _animatorIO :: !(Tree -> StepType -> Animation -> (Coords -> Location) -> RenderState -> IO (Maybe Animation)) , _animatorColorFromFrame :: !(Frame -> Color8Code) } ` to: ` data Animator a = Animator { _animatorPure :: (Iteration -> (Coords -> Location) -> Tree -> Tree) , _animatorIO :: (Tree -> StepType -> Animation -> (Coords -> Location) -> RenderState -> IO (Maybe Animation)) , _animatorColorFromFrame :: (Frame -> Color8Code) } Also, here is my stack version if it matters: ` stack version: `1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 hpack-0.15.0` Could this be a compiler bug? The code is available at https://github.com/OlivierSohn/hamazed I could try to create another program that reproduces the issue more easily (without having to play the game), just let me know if you need it. Thank you, Olivier -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 12:10:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 12:10:45 -0000 Subject: [GHC] #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.b354594401705021ae50128e28745167@haskell.org> #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | 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 OlivierSohn: Old description: > Hello, > > in https://github.com/OlivierSohn/hamazed/issues/1 I describe the > following issue: > > When compiling on OSX with optimizations (`stack clean && stack build` > with resolver `lts-9.12` (ghc 8.0.2)), the program loops infinitely (400% > CPU, and execution is blocked) when an animation is triggered, if the > function `Animation.animate'` is not inlined. > > The bug is visible at this commit : > https://github.com/OlivierSohn/hamazed/commit/9f25223ef0502f91cd9633654bdb172f714c3920 > (to reproduce, shoot at a number in the game) > > I originally fixed this behaviour by declaring the function that consumes > the Animator record INLINE : > https://github.com/OlivierSohn/hamazed/commit/597619bb14974d2bbacfb284a9e276a7cf2d2f52 > > And later, I found that another way to fix the behaviour is to remove the > strict annotation on the fields of the record "Animator", ie changing > > ` > data Animator a = Animator { > _animatorPure :: !(Iteration -> (Coords -> Location) -> Tree -> Tree) > , _animatorIO :: !(Tree -> StepType -> Animation -> (Coords -> > Location) -> RenderState -> IO (Maybe Animation)) > , _animatorColorFromFrame :: !(Frame -> Color8Code) > } > ` > > to: > > ` > data Animator a = Animator { > _animatorPure :: (Iteration -> (Coords -> Location) -> Tree -> Tree) > , _animatorIO :: (Tree -> StepType -> Animation -> (Coords -> > Location) -> RenderState -> IO (Maybe Animation)) > , _animatorColorFromFrame :: (Frame -> Color8Code) > } > > Also, here is my stack version if it matters: > ` > stack version: `1.3.2, Git revision > 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 > hpack-0.15.0` > > Could this be a compiler bug? > > The code is available at https://github.com/OlivierSohn/hamazed > > I could try to create another program that reproduces the issue more > easily (without having to play the game), just let me know if you need > it. > > Thank you, > Olivier New description: Hello, in https://github.com/OlivierSohn/hamazed/issues/1 I describe the following issue: When compiling on OSX with optimizations (`stack clean && stack build` using resolver `lts-9.12` (ghc 8.0.2)), the program loops infinitely (400% CPU, and execution is blocked) when an animation is triggered in the game. When compiling without optimizations, there is not this bug. The bug is visible at this commit : https://github.com/OlivierSohn/hamazed/commit/9f25223ef0502f91cd9633654bdb172f714c3920 (to reproduce, shoot at a number in the game) I originally fixed this behaviour by pragma-declaring INLINE the function `Animation.animate' (this function consumes an Animator record) : https://github.com/OlivierSohn/hamazed/commit/597619bb14974d2bbacfb284a9e276a7cf2d2f52 And later, I found that another way to fix the behaviour is to remove the strict annotation on the fields of the record "Animator", ie changing ` data Animator a = Animator { _animatorPure :: !(Iteration -> (Coords -> Location) -> Tree -> Tree) , _animatorIO :: !(Tree -> StepType -> Animation -> (Coords -> Location) -> RenderState -> IO (Maybe Animation)) , _animatorColorFromFrame :: !(Frame -> Color8Code) } ` to: ` data Animator a = Animator { _animatorPure :: (Iteration -> (Coords -> Location) -> Tree -> Tree) , _animatorIO :: (Tree -> StepType -> Animation -> (Coords -> Location) -> RenderState -> IO (Maybe Animation)) , _animatorColorFromFrame :: (Frame -> Color8Code) } Could this be a compiler bug? The code is available at https://github.com/OlivierSohn/hamazed I could try to create another program that reproduces the issue more easily (without having to play the game), just let me know if you need it. Also, here is my stack version if it matters: ` stack version: `1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 hpack-0.15.0` Thank you, Olivier -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 14:19:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 14:19:28 -0000 Subject: [GHC] #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.1b7aef0ef938871ec256e8de1d1ce9e3@haskell.org> #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, it could be a compiler bug, but a more self-contained repro case would be far far easier to deal with. Thank you! Does it happen with 8.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 14:26:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 14:26:38 -0000 Subject: [GHC] #14523: Confusing link error when specifying the same object repeatedly Message-ID: <051.555be4f2d1af34462145f93286f17aa9@haskell.org> #14523: Confusing link error when specifying the same object repeatedly -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given {{{foo.hs}}} containing {{{main = print 1}}} and {{{foo.c}}} containing {{{void foo(){} }}}, if you run: {{{ $ ghc foo.o foo.hs C:\Neil\temp\dupe-name>ghc foo.hs foo.o [1 of 1] Compiling Main ( foo.hs, foo.o ) Linking foo.exe ... foo.o:fake:(.data+0x0): multiple definition of `__stginit_Main' foo.o:fake:(.data+0x0): first defined here foo.o:fake:(.data+0x10): multiple definition of `Main_main_closure' foo.o:fake:(.data+0x10): first defined here foo.o:fake:(.text+0x18): multiple definition of `Main_main_info' foo.o:fake:(.text+0x18): first defined here foo.o:fake:(.data+0x30): multiple definition of `ZCMain_main_closure' foo.o:fake:(.data+0x30): first defined here foo.o:fake:(.text+0x88): multiple definition of `ZCMain_main_info' foo.o:fake:(.text+0x88): first defined here foo.o:fake:(.data+0x70): multiple definition of `Main_zdtrModule_closure' foo.o:fake:(.data+0x70): first defined here collect2.exe: error: ld returned 1 exit status `gcc.exe' failed in phase `Linker'. (Exit code: 1) }}} It seems GHC compiles both {{{foo.hs}}} and {{{foo.c}}} to {{{foo.o}}}, and then links {{{foo.o}}} twice. Sometimes {{{foo.hs}}} writes last, sometimes {{{foo.c}}} so the error can change. I found the error quite confusing, until I realised what it was doing. One solution might be before linking {{{.o}}} files GHC does {{{canonicalizePath}}} on all the object files, and if any are duplicates, it raises a cleaner error. That check would also catch {{{ghc foo.hs bar.o bar.o}}} as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 14:27:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 14:27:01 -0000 Subject: [GHC] #14523: Confusing link error when specifying the same object repeatedly In-Reply-To: <051.555be4f2d1af34462145f93286f17aa9@haskell.org> References: <051.555be4f2d1af34462145f93286f17aa9@haskell.org> Message-ID: <066.bb8dd19636b8805073c622407109713d@haskell.org> #14523: Confusing link error when specifying the same object repeatedly -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 15:41:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 15:41:04 -0000 Subject: [GHC] #14524: Use sortOn instead of sortWith Message-ID: <047.0bc1966b1ffbd164ce0f293aadc3e1a2@haskell.org> #14524: Use sortOn instead of sortWith -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `sortWith`provides the same functionality as `sortOn` from `Data.List`. As sortOn is already part of Prelude it makes sense for the GHC source to use it as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 15:46:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 15:46:08 -0000 Subject: [GHC] #14524: Use sortOn instead of sortWith In-Reply-To: <047.0bc1966b1ffbd164ce0f293aadc3e1a2@haskell.org> References: <047.0bc1966b1ffbd164ce0f293aadc3e1a2@haskell.org> Message-ID: <062.84632855754acca7a4b8b5f189387acc@haskell.org> #14524: Use sortOn instead of sortWith -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 nomeata): `SortOn` is there since 4.8, which, according to https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries/VersionHistory corresponds to GHC-7.10.1 – oh yes, this is definitely around for long enough. A differential revision with that change is will probably be well- received. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 17:02:48 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 17:02:48 -0000 Subject: [GHC] #14262: fdReady cannot wait more than 49 days In-Reply-To: <042.48524b8eed487d5020c916aed0a23739@haskell.org> References: <042.48524b8eed487d5020c916aed0a23739@haskell.org> Message-ID: <057.0c1c19c719bf1076aa9f66f8c3785f3d@haskell.org> #14262: fdReady cannot wait more than 49 days -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8684, #13497, | Differential Rev(s): #14267 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f209e6672fe33235bd1d4c20c87894021cf3bbc8/ghc" f209e667/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f209e6672fe33235bd1d4c20c87894021cf3bbc8" base: fdReady(): Fix timeouts > ~49 days overflowing. Fixes #14262. On 64-bit UNIX and Windows, Haskell `Int` has 64 bits but C `int msecs` has 32 bits, resulting in an overflow. This commit fixes it by switching fdReady() to take int64_t, into which a Haskell `Int` will always fit. (Note we could not switch to `long long` because that is 32 bit on 64-bit Windows machines.) Further, to be able to actually wait longer than ~49 days, we put loops around the waiting syscalls (they all accept only 32-bit integers). Note the timer signal would typically interrupt the syscalls before the ~49 days are over, but you can run Haskell programs without the timer signal, an we want it to be correct in all cases. Reviewers: bgamari, austin, hvr, NicolasT, Phyx Reviewed By: bgamari, Phyx Subscribers: syd, Phyx, rwbarton, thomie GHC Trac Issues: #14262 Differential Revision: https://phabricator.haskell.org/D4011 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 17:32:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 17:32:20 -0000 Subject: [GHC] #13157: Opportunity to improve case-of-case In-Reply-To: <046.6083067245a0621fcdfe440b63017d34@haskell.org> References: <046.6083067245a0621fcdfe440b63017d34@haskell.org> Message-ID: <061.ea9a0a3da4c08bbb3aeff04fe0a61cf2@haskell.org> #13157: Opportunity to improve case-of-case -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints 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 nickkuk): It seems to be fixed, namely, GHC-8.2.1 with "-ddump-simpl -O" gives {{{ f = \ (@ t_a1TX) (g_ap0 :: t_a1TX -> Bool) (x_ap1 :: t_a1TX) -> case g_ap0 x_ap1 of { __DEFAULT -> GHC.Types.True } }}} I will try to add test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 18:01:00 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 18:01:00 -0000 Subject: [GHC] #14524: Use sortOn instead of sortWith In-Reply-To: <047.0bc1966b1ffbd164ce0f293aadc3e1a2@haskell.org> References: <047.0bc1966b1ffbd164ce0f293aadc3e1a2@haskell.org> Message-ID: <062.a6d007b6757ffea652e96739f11308ab@haskell.org> #14524: Use sortOn instead of sortWith -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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:D4233 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * owner: (none) => AndreasK * differential: => Phab:D4233 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 19:59:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 19:59:01 -0000 Subject: [GHC] #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.94bba7daeebc8a3d630f8ff9ba542c78@haskell.org> #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by OlivierSohn): Replying to [comment:3 simonpj]: > Yes, it could be a compiler bug, but a more self-contained repro case would be far far easier to deal with. Thank you! > > Does it happen with 8.2? Ok, I'll try to reduce the problem to a minimal amount of code. I was waiting to be sure that it was not a problem in my code before digging a little deeper. I don't know if it's a bug fixed by 8.2, I'll try that too. First I need to understand how to build using ghc directly instead of relying on stack, because latest stack version references 8.0.2 :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 21:29:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 21:29:19 -0000 Subject: [GHC] #14262: fdReady cannot wait more than 49 days In-Reply-To: <042.48524b8eed487d5020c916aed0a23739@haskell.org> References: <042.48524b8eed487d5020c916aed0a23739@haskell.org> Message-ID: <057.456d7681190a0720c5d0fef4cd10e089@haskell.org> #14262: fdReady cannot wait more than 49 days -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8684, #13497, | Differential Rev(s): #14267 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 Old description: > {{{ > import System.IO > hWaitForInput stdin 4294968296 > }}} > > This code waits for 1 second instead of 49.something days. > > The culprit: > > {{{ > hWaitForInput :: Handle -> Int -> IO Bool > fdReady(..., int msecs, ...) > }}} > > Haskell `Int` is usally 64 bits. C `int` is usually 32 bits. > > Called here: > > {{{ > ready :: FD -> Bool -> Int -> IO Bool > ready fd write msecs = do > r <- throwErrnoIfMinus1Retry "GHC.IO.FD.ready" $ > fdReady (fdFD fd) (fromIntegral $ fromEnum $ write) > (fromIntegral msecs) > > foreign import ccall safe "fdReady" > fdReady :: CInt -> CInt -> CInt -> CInt -> IO CInt > }}} > > We `fromIntegral` `Int` to `CInt` (== `Int32`), overflowing. New description: {{{#!hs import System.IO hWaitForInput stdin 4294968296 }}} This code waits for 1 second instead of 49.something days. The culprit: {{{#!hs hWaitForInput :: Handle -> Int -> IO Bool fdReady(..., int msecs, ...) }}} Haskell `Int` is usally 64 bits. C `int` is usually 32 bits. Called here: {{{#!hs ready :: FD -> Bool -> Int -> IO Bool ready fd write msecs = do r <- throwErrnoIfMinus1Retry "GHC.IO.FD.ready" $ fdReady (fdFD fd) (fromIntegral $ fromEnum $ write) (fromIntegral msecs) foreign import ccall safe "fdReady" fdReady :: CInt -> CInt -> CInt -> CInt -> IO CInt }}} We `fromIntegral` `Int` to `CInt` (== `Int32`), overflowing. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 21:30:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 21:30:27 -0000 Subject: [GHC] #14504: Nofib is broken on Windows In-Reply-To: <046.cc1daf3bad5a64611f515c88109eb2f4@haskell.org> References: <046.cc1daf3bad5a64611f515c88109eb2f4@haskell.org> Message-ID: <061.aee273aa1051ff575c52fb27f1e6c4d1@haskell.org> #14504: Nofib is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: NoFib benchmark | Version: 8.2.1 suite | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4222 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged in 599243e73384e1b74a07f175b2d7324778a0f79c. Still need to test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 21:32:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 21:32:43 -0000 Subject: [GHC] #14518: GHC panic when trying to install Stack-1.5.1 with Cabal. In-Reply-To: <046.8cc838f5db9c89e4f01bf5d374aa733b@haskell.org> References: <046.8cc838f5db9c89e4f01bf5d374aa733b@haskell.org> Message-ID: <061.3a38d0a492cd7eea2d4a3450e26d5f8c@haskell.org> #14518: GHC panic when trying to install Stack-1.5.1 with Cabal. -------------------------------------+------------------------------------- Reporter: adgalad | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.4 Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #12479 Comment: This is #12479. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 24 23:44:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Nov 2017 23:44:32 -0000 Subject: [GHC] #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.bb56cb61ac5713df66137484b3db04a7@haskell.org> #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | 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): * milestone: => 8.2.3 Old description: > Hello, > > in https://github.com/OlivierSohn/hamazed/issues/1 I describe the > following issue: > > When compiling on OSX with optimizations (`stack clean && stack build` > using resolver `lts-9.12` (ghc 8.0.2)), the program loops infinitely > (400% CPU, and execution is blocked) when an animation is triggered in > the game. When compiling without optimizations, there is not this bug. > > The bug is visible at this commit : > https://github.com/OlivierSohn/hamazed/commit/9f25223ef0502f91cd9633654bdb172f714c3920 > (to reproduce, shoot at a number in the game) > > I originally fixed this behaviour by pragma-declaring INLINE the function > `Animation.animate' (this function consumes an Animator record) : > https://github.com/OlivierSohn/hamazed/commit/597619bb14974d2bbacfb284a9e276a7cf2d2f52 > > And later, I found that another way to fix the behaviour is to remove the > strict annotation on the fields of the record "Animator", ie changing > > ` > data Animator a = Animator { > _animatorPure :: !(Iteration -> (Coords -> Location) -> Tree -> Tree) > , _animatorIO :: !(Tree -> StepType -> Animation -> (Coords -> > Location) -> RenderState -> IO (Maybe Animation)) > , _animatorColorFromFrame :: !(Frame -> Color8Code) > } > ` > > to: > > ` > data Animator a = Animator { > _animatorPure :: (Iteration -> (Coords -> Location) -> Tree -> Tree) > , _animatorIO :: (Tree -> StepType -> Animation -> (Coords -> > Location) -> RenderState -> IO (Maybe Animation)) > , _animatorColorFromFrame :: (Frame -> Color8Code) > } > > Could this be a compiler bug? > > The code is available at https://github.com/OlivierSohn/hamazed > > I could try to create another program that reproduces the issue more > easily (without having to play the game), just let me know if you need > it. > > Also, here is my stack version if it matters: > ` > stack version: `1.3.2, Git revision > 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 > hpack-0.15.0` > > Thank you, > Olivier New description: Hello, in https://github.com/OlivierSohn/hamazed/issues/1 I describe the following issue: When compiling on OSX with optimizations (`stack clean && stack build` using resolver `lts-9.12` (ghc 8.0.2)), the program loops infinitely (400% CPU, and execution is blocked) when an animation is triggered in the game. When compiling without optimizations, there is not this bug. The bug is visible at this commit : https://github.com/OlivierSohn/hamazed/commit/9f25223ef0502f91cd9633654bdb172f714c3920 (to reproduce, shoot at a number in the game) I originally fixed this behaviour by pragma-declaring INLINE the function `Animation.animate' (this function consumes an Animator record) : https://github.com/OlivierSohn/hamazed/commit/597619bb14974d2bbacfb284a9e276a7cf2d2f52 And later, I found that another way to fix the behaviour is to remove the strict annotation on the fields of the record "Animator", ie changing {{{ data Animator a = Animator { _animatorPure :: !(Iteration -> (Coords -> Location) -> Tree -> Tree) , _animatorIO :: !(Tree -> StepType -> Animation -> (Coords -> Location) -> RenderState -> IO (Maybe Animation)) , _animatorColorFromFrame :: !(Frame -> Color8Code) } }}} to: {{{ data Animator a = Animator { _animatorPure :: (Iteration -> (Coords -> Location) -> Tree -> Tree) , _animatorIO :: (Tree -> StepType -> Animation -> (Coords -> Location) -> RenderState -> IO (Maybe Animation)) , _animatorColorFromFrame :: (Frame -> Color8Code) } }}} Could this be a compiler bug? The code is available at https://github.com/OlivierSohn/hamazed I could try to create another program that reproduces the issue more easily (without having to play the game), just let me know if you need it. Also, here is my stack version if it matters: {{{ stack version: `1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 hpack-0.15.0` }}} Thank you, Olivier -- Comment: For what it's worth the repo build for me with 8.2.1, {{{ $ git clone ​https://github.com/OlivierSohn/hamazed $ cd hamazed $ git checkout 9f25223ef0502f91cd9633654bdb172f714c3920 $ git clone https://github.com/OlivierSohn/ansi-terminal.git $ git -C ansi-terminal checkout e6a2b1ff2e1aebd902c1791583b80ef481f370c5 $ echo "packages: ., ansi-terminal" >> cabal.project $ cabal new-build all --allow-newer }}} Unfortunately I'm quite lost regarding the game itself. I found that pressing "Enter" makes numbers start flying about; however the `s`, `e`, `d`, `f` keys don't appear to do anything. This appears to be the case with both 8.2.2 and 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 25 02:07:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Nov 2017 02:07:30 -0000 Subject: [GHC] #14525: Backpack doesn't work with CPP Message-ID: <045.32abb777bece6efc430ddbb385cddc79@haskell.org> #14525: Backpack doesn't work with CPP -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Steps to repro: 1. Create a package with a signature and a module which imports it 2. Add `{-# LANGUAGE CPP #-}` to the module Expected result: it works Actual result: {{{ : unknown package: hole }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 25 02:11:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Nov 2017 02:11:33 -0000 Subject: [GHC] #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.07e84c35467559f9c0b07b574025f07f@haskell.org> #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by OlivierSohn): Replying to [comment:5 bgamari]: > For what it's worth the repo build for me with 8.2.1, > {{{ > $ git clone ​https://github.com/OlivierSohn/hamazed > $ cd hamazed > $ git checkout 9f25223ef0502f91cd9633654bdb172f714c3920 > $ git clone https://github.com/OlivierSohn/ansi-terminal.git > $ git -C ansi-terminal checkout e6a2b1ff2e1aebd902c1791583b80ef481f370c5 > $ echo "packages: ., ansi-terminal" >> cabal.project > $ cabal new-build all --allow-newer > }}} > Unfortunately I'm quite lost regarding the game itself. I found that pressing "Enter" makes numbers start flying about; however the `s`, `e`, `d`, `f` keys don't appear to do anything. This appears to be the case with both 8.2.2 and 8.0.2. @bgamari, I suppose you are on windows? On windows there is a bug which makes it impossible to set stdin buffering mode to "unbuffered" (I explain a bit more in BACKLOG.md file, in "Windows" chapter), this explains the behaviour you see: when pressing Enter, stdin is flushed. I tried to circumvent this problem but didn't finish the fix. In the meantime I made a program that allows to reproduce the behaviour with minimal code : it is branch https://github.com/OlivierSohn/hamazed/tree/repro-ghc-14521-A When running the program, the expected output is: ` Before rendering animations animation is rendered After rendering animations ` What I see with 8.0.2 when compiled with optimizations is: ` Before rendering animations ` I also documented in the code what changes make the problem disappear I'd be interested if someone can build with optimizations with 8.2.2 and run the program and report on the output ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 25 02:21:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Nov 2017 02:21:26 -0000 Subject: [GHC] #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.f94a1ba9198acf6b8cb9f0d10400ace8@haskell.org> #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | 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 OlivierSohn: Old description: > Hello, > > in https://github.com/OlivierSohn/hamazed/issues/1 I describe the > following issue: > > When compiling on OSX with optimizations (`stack clean && stack build` > using resolver `lts-9.12` (ghc 8.0.2)), the program loops infinitely > (400% CPU, and execution is blocked) when an animation is triggered in > the game. When compiling without optimizations, there is not this bug. > > The bug is visible at this commit : > https://github.com/OlivierSohn/hamazed/commit/9f25223ef0502f91cd9633654bdb172f714c3920 > (to reproduce, shoot at a number in the game) > > I originally fixed this behaviour by pragma-declaring INLINE the function > `Animation.animate' (this function consumes an Animator record) : > https://github.com/OlivierSohn/hamazed/commit/597619bb14974d2bbacfb284a9e276a7cf2d2f52 > > And later, I found that another way to fix the behaviour is to remove the > strict annotation on the fields of the record "Animator", ie changing > > {{{ > data Animator a = Animator { > _animatorPure :: !(Iteration -> (Coords -> Location) -> Tree -> Tree) > , _animatorIO :: !(Tree -> StepType -> Animation -> (Coords -> > Location) -> RenderState -> IO (Maybe Animation)) > , _animatorColorFromFrame :: !(Frame -> Color8Code) > } > }}} > > to: > > {{{ > data Animator a = Animator { > _animatorPure :: (Iteration -> (Coords -> Location) -> Tree -> Tree) > , _animatorIO :: (Tree -> StepType -> Animation -> (Coords -> > Location) -> RenderState -> IO (Maybe Animation)) > , _animatorColorFromFrame :: (Frame -> Color8Code) > } > }}} > > Could this be a compiler bug? > > The code is available at https://github.com/OlivierSohn/hamazed > > I could try to create another program that reproduces the issue more > easily (without having to play the game), just let me know if you need > it. > > Also, here is my stack version if it matters: > {{{ > stack version: `1.3.2, Git revision > 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 > hpack-0.15.0` > }}} > > Thank you, > Olivier New description: Hello, in https://github.com/OlivierSohn/hamazed/issues/1 I describe the following issue: When compiling on OSX with optimizations (`stack clean && stack build` using resolver `lts-9.12` (ghc 8.0.2)), the program loops infinitely (400% CPU, and execution is blocked) when an animation is triggered in the game. When compiling without optimizations, there is not this bug. The bug is visible in the full game at this commit : https://github.com/OlivierSohn/hamazed/commit/9f25223ef0502f91cd9633654bdb172f714c3920 (to reproduce, shoot at a number in the game) And this commit shows a program with minimal code to reproduce the issue : https://github.com/OlivierSohn/hamazed/commit/30b0f703565a4150d686a36a4dfe9d36ce5989f1 The expected output of the program is {{{ Before rendering animations animation is rendered After rendering animations }}} What I observe is {{{ Before rendering animations }}} I found several ways to circumvent the problem, wrote them in the code to help debugging. Also, here is my stack version if it matters: {{{ stack version: `1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 hpack-0.15.0` }}} Thank you, Olivier -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 25 03:12:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Nov 2017 03:12:41 -0000 Subject: [GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends In-Reply-To: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> References: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> Message-ID: <060.b84237cdc7ad3b09136ddef846af707d@haskell.org> #14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: ghc-pkg | Version: 8.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): Phab:D4159 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ntc2): * cc: ntc2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 25 03:16:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Nov 2017 03:16:26 -0000 Subject: [GHC] #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA In-Reply-To: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> References: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> Message-ID: <058.b4a5bb76775600ca9a27bdd30c66b1e5@haskell.org> #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | https://github.com/ntc2/ghc-8.2.1 | -regex-lazy-text-bug Blocked By: | Blocking: Related Tickets: 13745 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ntc2): Having "unusable due to shadowed dependencies" trouble with the GHC 8.2.1 I built from source when trying to build my test code. Links to possibly related issues and a patch: - https://github.com/haskell/cabal/issues/4728 - https://github.com/commercialhaskell/stack/issues/3554 - https://phabricator.haskell.org/D4159 - https://ghc.haskell.org/trac/ghc/ticket/14381 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 25 05:16:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Nov 2017 05:16:01 -0000 Subject: [GHC] #14525: Backpack doesn't work with CPP In-Reply-To: <045.32abb777bece6efc430ddbb385cddc79@haskell.org> References: <045.32abb777bece6efc430ddbb385cddc79@haskell.org> Message-ID: <060.ef3a46641463ee7e21d95d721f3ea83e@haskell.org> #14525: Backpack doesn't work with CPP -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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): Phab:D4234 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D4234 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 25 13:37:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Nov 2017 13:37:25 -0000 Subject: [GHC] #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) In-Reply-To: <047.9478e62bd80e36e2a95f7745037003bc@haskell.org> References: <047.9478e62bd80e36e2a95f7745037003bc@haskell.org> Message-ID: <062.25520d1fb0d7a8c9acea09865c92ac7b@haskell.org> #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) -------------------------------------+------------------------------------- Reporter: takenobu | Owner: takenobu Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13126 #9224 | Differential Rev(s): Phab:D4235 Wiki Page: | -------------------------------------+------------------------------------- Changes (by takenobu): * status: new => patch * differential: => Phab:D4235 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 25 13:44:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Nov 2017 13:44:08 -0000 Subject: [GHC] #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) In-Reply-To: <047.9478e62bd80e36e2a95f7745037003bc@haskell.org> References: <047.9478e62bd80e36e2a95f7745037003bc@haskell.org> Message-ID: <062.75f6dcf28ff0153eaa49b0d8d430d54d@haskell.org> #14473: Implement Underscores in Numeric Literals Proposal (NumericUnderscores extension) -------------------------------------+------------------------------------- Reporter: takenobu | Owner: takenobu Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13126 #9224 | Differential Rev(s): Phab:D4235 Wiki Page: | -------------------------------------+------------------------------------- Comment (by takenobu): I submitted a patch Phab:D4235. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 25 15:42:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Nov 2017 15:42:21 -0000 Subject: [GHC] #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.608e12cf71505c53c8494dcfb20c32af@haskell.org> #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): Replying to [comment:4 OlivierSohn]: > [...] First I need to understand how to build using ghc directly instead of relying on stack, because latest stack version references 8.0.2 :) Just FYI: Stackage nightly builds use 8.2.1/8.2.2 for some time now, just use `stack --resolver=nightly ...` or even more specifically e.g. `stack --resolver=nightly-2017-11-25 ...`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 25 20:03:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Nov 2017 20:03:35 -0000 Subject: [GHC] #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.d986f36a01f08564b0e7422410d041e6@haskell.org> #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by OlivierSohn): Replying to [comment:8 svenpanne]: > Just FYI: Stackage nightly builds use 8.2.1/8.2.2 for some time now, just use `stack --resolver=nightly ...` or even more specifically e.g. `stack --resolver=nightly-2017-11-25 ...`. Thanks, using the nightly resolver I could verify that the behaviour is the same on 8.2.2: {{{ 2017-11-25 21:01:48.402994: [debug] Run process: /Users/Olivier/Dev/hs.maze/.stack- work/install/x86_64-osx/nightly-2017-11-25/8.2.2/bin/hamazed-exe @(Stack/Exec.hs:67:5) Before rendering animations }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 25 20:08:18 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Nov 2017 20:08:18 -0000 Subject: [GHC] #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.d98977889722072474cc91a843a1ad5e@haskell.org> #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by OlivierSohn): * version: 8.0.2 => 8.2.2 Old description: > Hello, > > in https://github.com/OlivierSohn/hamazed/issues/1 I describe the > following issue: > > When compiling on OSX with optimizations (`stack clean && stack build` > using resolver `lts-9.12` (ghc 8.0.2)), the program loops infinitely > (400% CPU, and execution is blocked) when an animation is triggered in > the game. When compiling without optimizations, there is not this bug. > > The bug is visible in the full game at this commit : > https://github.com/OlivierSohn/hamazed/commit/9f25223ef0502f91cd9633654bdb172f714c3920 > (to reproduce, shoot at a number in the game) > > And this commit shows a program with minimal code to reproduce the issue > : > https://github.com/OlivierSohn/hamazed/commit/30b0f703565a4150d686a36a4dfe9d36ce5989f1 > > The expected output of the program is > > {{{ > Before rendering animations > animation is rendered > After rendering animations > }}} > > What I observe is > > {{{ > Before rendering animations > }}} > > I found several ways to circumvent the problem, wrote them in the code to > help debugging. > > Also, here is my stack version if it matters: > {{{ > stack version: `1.3.2, Git revision > 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 > hpack-0.15.0` > }}} > > Thank you, > Olivier New description: Hello, in https://github.com/OlivierSohn/hamazed/issues/1 I describe the following issue: **(Edit : the same behaviour exists with ghc 8.2.2)** When compiling on OSX with optimizations (`stack clean && stack build` using resolver `lts-9.12` (ghc 8.0.2)), the program loops infinitely (400% CPU, and execution is blocked) when an animation is triggered in the game. When compiling without optimizations, there is not this bug. The bug is visible in the full game at this commit : https://github.com/OlivierSohn/hamazed/commit/9f25223ef0502f91cd9633654bdb172f714c3920 (to reproduce, shoot at a number in the game) And this commit shows a program with minimal code to reproduce the issue : https://github.com/OlivierSohn/hamazed/commit/30b0f703565a4150d686a36a4dfe9d36ce5989f1 The expected output of the program is {{{ Before rendering animations animation is rendered After rendering animations }}} What I observe is {{{ Before rendering animations }}} I found several ways to circumvent the problem, wrote them in the code to help debugging. Also, here is my stack version if it matters: {{{ stack version: `1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 hpack-0.15.0` }}} Thank you, Olivier -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 25 20:12:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Nov 2017 20:12:05 -0000 Subject: [GHC] #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.f52e2c437ca37aa3ebf211e8bf4b4122@haskell.org> #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by OlivierSohn): Replying to [comment:3 simonpj]: > Yes, it could be a compiler bug, but a more self-contained repro case would be far far easier to deal with. Thank you! > > Does it happen with 8.2? I verified that it happens also with 8.2.2, and made a minimal repro case in this branch : https://github.com/OlivierSohn/hamazed/tree/repro- ghc-14521-A It can be built and run with this command: {{{ stack build --pedantic --resolver=nightly --install-ghc&& stack exec hamazed-exe --resolver=nightly -v }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 26 01:57:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Nov 2017 01:57:14 -0000 Subject: [GHC] #14526: GHC fails to configure on MacOS if Cuda is installed Message-ID: <044.b4ecd2cf118d3da39dbf347707988ebb@haskell.org> #14526: GHC fails to configure on MacOS if Cuda is installed -------------------------------------+------------------------------------- Reporter: nehal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.2 Keywords: Cuda | Operating System: MacOS X Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, I had the following issue trying to build ghc (indirectly via stack) {{{ [error] Running /usr/bin/make install in directory /Users/nehal/.stack/programs/x86_64-osx/ghc-8.0.2.temp/ghc-8.0.2/ exited with ExitFailure 2 mk/config.mk:521: *** missing separator. Stop. @(Stack/Setup.hs:991:21) 2017-10-16 07:16:01.831719: [error] Error: Error encountered while installing GHC with make install run in /Users/nehal/.stack/programs/x86_64-osx/ghc-8.0.2.temp/ghc-8.0.2/ }}} Here is the line from `mk/config.mk:521`: {{{ 519 WhatGccIsCalled = /usr/bin/gcc 520 GccVersion = 9.0.0 521 8.0 522 ifeq "$(phase)" "0" ... }}} output from gcc: {{{ nehal$ gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 9.0.0 (clang-900.0.37) Target: x86_64-apple-darwin16.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin Found CUDA installation: /usr/local/cuda, version 8.0 }}} It looks like the version detection is getting confused by the cuda installation (and so is thinking the version is something like `"9.0.0\n8.0"`) This could be something for further upstream (e.g. autotools mainainters), but I'm just rebooting my "try to grok Haskell" efforts, so I am going to take the lazy approach and report it here.... Thanks for ghc! (downstream bug report is here: https://github.com/commercialhaskell/stack/issues/1582#issuecomment-346917482 -- two others have hit this in the past month or so) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 26 12:04:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Nov 2017 12:04:27 -0000 Subject: [GHC] #14527: Warn on recursive bindings Message-ID: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> #14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 you accidentally write something like `let x = .. x ...` it can take hours to realize where you made your mistake. This hits me once in a while, and my colleagues often. I'd propose e.g. `-Wrecursive-bindings` that says: {{{ warning: [-Wrecursive-bindings] Recursive binding for `x` in let x = length x }}} This applies to `let`, `where` and top-level pattern bindings. I believe that in practice, I only actually use real recursive bindings once in a while. So I might be bold enough to encourage enabling it in `-Wall` for a future major GHC release. With the compromise that if you have the warning enabled but in one specific place, you want a recursive binding, you can use the `~` tilde to say "I really mean it", e.g. {{{let ~ones = 1 : ones}}} That seems like a nice balance to say "I know what I'm doing in this case". So the warning could be more helpful, like: {{{ warning: [-Wrecursive-bindings] Recursive binding for `ones` in let ones = length ones If intentional, use the tilde marker on the name like this: let ~ones = length ones }}} In Intero if I were to implement a prototype of this check, I'd probably do this, after renaming: 1. Use SYB to collect all variable bindings from the pattern. 2. Use SYB to listify all mentions of any of these variables in the RHS and any guards or where clauses. If the list is non-empty, then trigger the error. A transformation function {{{[Name] -> Pat -> Pat}}} would provide the AST with the offending name(s) tilded as {{{~x}}} for use in the error message. If there's general agreement, I could implement this change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 26 12:07:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Nov 2017 12:07:26 -0000 Subject: [GHC] #14527: Warn on recursive bindings In-Reply-To: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> References: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> Message-ID: <063.8e0b734cb67ee1057c28207b2c15f7f2@haskell.org> #14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Description changed by chrisdone: Old description: > When you accidentally write something like `let x = .. x ...` it can take > hours to realize where you made your mistake. This hits me once in a > while, and my colleagues often. > > I'd propose e.g. `-Wrecursive-bindings` that says: > > {{{ > warning: [-Wrecursive-bindings] > Recursive binding for `x` in > > let x = length x > }}} > > This applies to `let`, `where` and top-level pattern bindings. > > I believe that in practice, I only actually use real recursive bindings > once in a while. So I might be bold enough to encourage enabling it in > `-Wall` for a future major GHC release. > > With the compromise that if you have the warning enabled but in one > specific place, you want a recursive binding, you can use the `~` tilde > to say "I really mean it", e.g. > > {{{let ~ones = 1 : ones}}} > > That seems like a nice balance to say "I know what I'm doing in this > case". So the warning could be more helpful, like: > > {{{ > warning: [-Wrecursive-bindings] > Recursive binding for `ones` in > > let ones = length ones > > If intentional, use the tilde marker on the name like this: > > let ~ones = length ones > > }}} > > In Intero if I were to implement a prototype of this check, I'd probably > do this, after renaming: > > 1. Use SYB to collect all variable bindings from the pattern. > 2. Use SYB to listify all mentions of any of these variables in the RHS > and any guards or where clauses. > > If the list is non-empty, then trigger the error. A transformation > function {{{[Name] -> Pat -> Pat}}} would provide the AST with the > offending name(s) tilded as {{{~x}}} for use in the error message. > > If there's general agreement, I could implement this change. New description: When you accidentally write something like `let x = .. x ...` it can take hours to realize where you made your mistake. This hits me once in a while, and my colleagues often. I'd propose e.g. `-Wrecursive-bindings` that says: {{{ warning: [-Wrecursive-bindings] Recursive binding for `x` in let x = length x }}} This applies to `let`, `where` and top-level pattern bindings. I believe that in practice, I only actually use real recursive bindings once in a while. So I might be bold enough to encourage enabling it in `-Wall` for a future major GHC release. With the compromise that if you have the warning enabled but in one specific place, you want a recursive binding, you can use the `~` tilde to say "I really mean it", e.g. {{{let ~ones = 1 : ones}}} That seems like a nice balance to say "I know what I'm doing in this case". So the warning could be more helpful, like: {{{ warning: [-Wrecursive-bindings] Recursive binding for `ones` in let ones = length ones If intentional, use the tilde marker on the name like this: let ~ones = length ones }}} In Intero if I were to implement a prototype of this check, I'd probably do this, after renaming: 1. Use SYB to collect all variable bindings from the pattern. 2. Use SYB to listify all mentions of any of these variables in the RHS and any guards or where clauses. If the list is non-empty, then trigger the error. A transformation function {{{[Name] -> Pat -> Pat}}} would provide the AST with the offending name(s) tilded as {{{~x}}} for use in the error message. If there's general agreement, I could implement this change. **EDIT**: mutually recursive bindings apply here too. So {{{let x = y; y = x}}} by a regular occurs check. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 26 12:08:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Nov 2017 12:08:54 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.e363cbe86ce6a74b91531fce86f865ed@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 AndreasK): It took some time but I have a proof of concept in GHC. This means it falls back to the default algorithm if it encounters: * Non vanilla constructors (So only Haskell98 Constructors) * Records * Any of the pattern extensions. * I've only implemented the trivial left-to-right Heuristic so far. So keep this in mind for the rest of this comment: ---- == Examples Pretty much all of the trivial examples I had collected come out the same either way with -O But then it's not too surprising when using the left-to-right Heuristic. A gain at -O2: {{{ badMix :: Int# -> Int# -> Int# badMix 1# 1# = 1# badMix _ 2# = 1# badMix 1# 3# = 1# ------------------------------------------- = \ ds_dY4 ds1_dY5 -> case ds_dY4 of { __DEFAULT -> case ds1_dY5 of { __DEFAULT -> case badMix1 of wild2_00 { }; 2# -> 1# }; 1# -> case ds1_dY5 of { __DEFAULT -> case badMix1 of wild2_00 { }; 1# -> 1#; -- 2# -> 1#; This alternative is removed in the tree approach 3# -> 1# } } }}} However this doesn't apply when types are changed to Int -> Int -> a. Not yet sure why. I will first finish dealing with Records properly and then see if I can find more examples. At that point it should be somewhat clear if further work makes sense. ---- == Nofib Nofib give a mean of 0% for runtime but -0.1% for time lapsed. Min/Max where -1.9%/+1.8% for runtime. So there seems to be at least some potential there. I plan to see how it turns out when I finish work on Records and add a few Heuristics. If that gives the same result it's probably not worth it but we will see. ---- == Implementation === Size The size of that implementation is about 1100 additional Lines in it's current State. It's however pretty verbose for Haskell and some of it could be combined with existing functionality. Mostly because functions in DsUtil generally make some assumptions that won't hold for my algorithm so require slight adjustments. === Complexity I would say implementing the scheme itself so far was straight forward. What complicated/delayed matters most was figuring out the current codebase in general. In particular some comments in the desugarer were outdated to the point where they confused me more than they helped. There were invariants which contradicted the implementation, references to non-existant functions, the works. I've got a patch committed that fixed some of that but there is much room for improvement still. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 26 13:36:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Nov 2017 13:36:33 -0000 Subject: [GHC] #14527: Warn on recursive bindings In-Reply-To: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> References: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> Message-ID: <063.f322a43037e7b14a618fa01a26bb7528@haskell.org> #14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 saurabhnanda): * cc: saurabhnanda (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 26 14:50:12 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Nov 2017 14:50:12 -0000 Subject: [GHC] #14527: Warn on recursive bindings In-Reply-To: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> References: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> Message-ID: <063.4100e9f33bb2c19170154da83d3cfc7d@haskell.org> #14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 nh2): **GHC 7.10 already had this feature**, but it disappeared with 8.0, and it's not clear to me if intentionally or accidentally. It would be great to find out. In 7.10, you could simply used a BangPattern to forbid recursive variable bindings. Example {{{ Recursive bang-pattern or unboxed-tuple bindings aren't allowed: !x = x }}} And it said in the manual: {{{ a bang-pattern binding must be non-recursive }}} It was removed for GHC 8.0 in these commits: * https://github.com/ghc/ghc/commit/e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9 #diff-47b9f40b0ede605e7b6bcb330b43ad53L1678 * https://github.com/ghc/ghc/commit/46a03fbec#diff- 02e7842997523ff8a5ad0312df2edfe2L10348 The question is: Why was this removed? Was it accidental, or did people find a legitimate use case for strict recursive variable let bindings? If not, we could simply re-introduce that, without a language extension (though we might still add the proposed language extension to get warnings even without bangs). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 26 14:55:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Nov 2017 14:55:33 -0000 Subject: [GHC] #14527: Warn on recursive bindings In-Reply-To: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> References: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> Message-ID: <063.ba9ae8422ef225f44305d3f335d3b5eb@haskell.org> #14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 nh2): * cc: nh2, goldfire, adamse (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 26 15:05:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Nov 2017 15:05:19 -0000 Subject: [GHC] #14527: Warn on recursive bindings In-Reply-To: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> References: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> Message-ID: <063.eebfd56e32de4fdbdd4f6e7309449625@haskell.org> #14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 adamse): I cannot remember removing this warning intentionally. It might have been part of the bigger plan around {{{-XStrict}}} and the changes to the semantics of bang patterns it introduced. I'll dig around and see if I can find out if it was unintentional. Sorry for not responding on IRC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 26 15:49:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Nov 2017 15:49:06 -0000 Subject: [GHC] #14527: Warn on recursive bindings In-Reply-To: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> References: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> Message-ID: <063.8518ca2a0e8c1bf5fd60bca0ab4a3105@haskell.org> #14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 adamse): It has come back to me: allowing recursive banged bindings was by design. See https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/glasgow_exts.html #recursive-and-polymorphic-let-bindings for details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 26 15:53:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Nov 2017 15:53:10 -0000 Subject: [GHC] #14527: Warn on recursive bindings In-Reply-To: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> References: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> Message-ID: <063.12943ff9d7837e2c275da44da14a8db7@haskell.org> #14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 chrisdone): For context, Niklas and I were discussing this problem and I mentioned the !x restriction, only to discover that the restriction wasn't present on GHC 8. So Niklas digged and found the commit, but we weren't sure why. However, it's not quite true that GHC had ''this'' feature. Certainly, getting {{{!x}}} to disable recursion back into GHC should be much easier to convince GHC maintainers to add it back, assuming it was removed accidentally. Maybe that belongs in a separate but related ticket. More generally speaking, self-referential variables in my experience are almost always a mistake and ''once in a while'' an intentional thing for me. So it would actually be nice if GHC warned about it and I had to put an explicit `~` in the ''few times'' I wanted it, rather than `!` ''everywhere'', just to avoid the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 26 18:14:37 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Nov 2017 18:14:37 -0000 Subject: [GHC] #14527: Warn on recursive bindings In-Reply-To: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> References: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> Message-ID: <063.1a666f834198fb17295cf7696c2c1feb@haskell.org> #14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): Given that both the ticket summary and comment:7 are really asking for a new flag and new behavior for `~`, I believe that this proposal falls within the scope of GHC's [[https://github.com/ghc-proposals/ghc- proposals|proposal process]]. Chrisdone, do you suppose you could submit a proposal? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 26 23:08:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Nov 2017 23:08:36 -0000 Subject: [GHC] #14528: LLVM's CallAnalyzer Breaks Message-ID: <044.27305b362437d331be59330d3192840e@haskell.org> #14528: LLVM's CallAnalyzer Breaks -------------------------------------+------------------------------------- Reporter: kavon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (LLVM) | Keywords: inline | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: 11295 | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found this issue while working on #11295. It seems that after first running `-mem2reg -inline` on some nofib programs, such as `imaginary/integrate` and `real/lift` (using `llvm-link` to roll the IR files together), running another pass that depends on LLVM's CallAnalyzer will cause `opt` to overflow the stack. For example, here are some pass sequences that break `opt` when optimizing `integrate`: * `-mem2reg -inline -gvn` * `-mem2reg -inline -instcombine` * `-mem2reg -inline -early-cse` This happens in LLVM 5 and tip-of-tree (LLVM 6). It probably is present in LLVM 4 as well. I'm working on putting together a reduced test case to report a bug to LLVM developers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 26 23:11:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Nov 2017 23:11:26 -0000 Subject: [GHC] #14528: LLVM's CallAnalyzer Breaks In-Reply-To: <044.27305b362437d331be59330d3192840e@haskell.org> References: <044.27305b362437d331be59330d3192840e@haskell.org> Message-ID: <059.e1c642c72bb5fc3e3e8ce1d5b2e63482@haskell.org> #14528: LLVM's CallAnalyzer Breaks -------------------------------------+------------------------------------- Reporter: kavon | Owner: kavon Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.2.1 Resolution: | Keywords: inline Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: 11295 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kavon): * owner: (none) => kavon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 03:32:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 03:32:49 -0000 Subject: [GHC] #14527: Warn on recursive bindings In-Reply-To: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> References: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> Message-ID: <063.a8c91aee50290997b84fb5537c1acb62@haskell.org> #14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 goldfire): In the levity polymorphism work, there were some annoying interactions between the treatment of strict and unlifted bindings and levity polymorphism. I don't recall the details, but it was necessary to edit the code in this area. As I was doing so, it seemed the code was confused around the restrictions on unlifted bindings vs. strict ones. There is no need to prevent strict recursive bindings, and so we don't. In the end, though, I don't think that disallowing strict recursive bindings is the real answer to this need (which I've shared) -- the warning route originally proposed would be far better. I agree with Ben that posting a proposal is the best next step. If I may be so bold as to comment prematurely, I would likely support such a proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 03:51:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 03:51:03 -0000 Subject: [GHC] #14514: Error messages: suggest annotating with higher-rank kind (was: Higher-Rank Kinds work in ADT but not GADT) In-Reply-To: <051.b76142fd8282a689e3ab27ed27c38d69@haskell.org> References: <051.b76142fd8282a689e3ab27ed27c38d69@haskell.org> Message-ID: <066.0f0d40444b19cd90aae5114f6cc48fe5@haskell.org> #14514: Error messages: suggest annotating with higher-rank kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: TypeInType, | TypeErrorMessages 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): * keywords: => TypeInType, TypeErrorMessages Old description: > Following code from > [https://github.com/goldfirere/triptych/blob/2e21a6be4419873c77a02c9a198379c76947b94c/extensibility/Extensible6.hs > Richard's 2016 Haskell Implementors' Workshop talk] (/ > [https://arxiv.org/abs/1610.04799 Trees That Grow]) works just fine > > {{{#!hs > {-# Language RankNTypes, KindSignatures, DataKinds, > TypeFamilyDependencies, TypeInType #-} > > import Data.Kind > > data TagTag = ETagTag | PTagTag > data ETag = VarTag > data PTag = VarPTag > > type family > Tag (ttag::TagTag) = (res :: Type) | res -> ttag where > Tag ETagTag = ETag > Tag PTagTag = PTag > > type WithAnyTag = forall tag. Tag tag -> Type > > -- data Exp (ext::WithAnyTag) where > -- Var :: ext VarTag -> Exp ext > data Exp (ext::WithAnyTag) = Var (ext VarTag) > }}} > > but replace `data Exp` with its commented-out GADT brethren and it stops > working > > {{{ > $ ghci -ignore-dot-ghci Weird.hs > GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( Weird.hs, interpreted ) > > Weird.hs:17:28: error: > • Expected kind ‘WithAnyTag’, but ‘ext1’ has kind ‘ETag -> *’ > • In the first argument of ‘Exp’, namely ‘ext’ > In the type ‘Exp ext’ > In the definition of data constructor ‘Var’ > | > 17 | Var :: ext VarTag -> Exp ext > | ^^^ > Failed, 0 modules loaded. > Prelude> > }}} > > The type synonym can be inlined, makes no difference. New description: The ticket below was posted because of confusion around higher-rank kinds. comment:3 suggests an error-message improvement, which I (goldfire) think is feasible. ------------------------------------ Following code from [https://github.com/goldfirere/triptych/blob/2e21a6be4419873c77a02c9a198379c76947b94c/extensibility/Extensible6.hs Richard's 2016 Haskell Implementors' Workshop talk] (/ [https://arxiv.org/abs/1610.04799 Trees That Grow]) works just fine {{{#!hs {-# Language RankNTypes, KindSignatures, DataKinds, TypeFamilyDependencies, TypeInType #-} import Data.Kind data TagTag = ETagTag | PTagTag data ETag = VarTag data PTag = VarPTag type family Tag (ttag::TagTag) = (res :: Type) | res -> ttag where Tag ETagTag = ETag Tag PTagTag = PTag type WithAnyTag = forall tag. Tag tag -> Type -- data Exp (ext::WithAnyTag) where -- Var :: ext VarTag -> Exp ext data Exp (ext::WithAnyTag) = Var (ext VarTag) }}} but replace `data Exp` with its commented-out GADT brethren and it stops working {{{ $ ghci -ignore-dot-ghci Weird.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Weird.hs, interpreted ) Weird.hs:17:28: error: • Expected kind ‘WithAnyTag’, but ‘ext1’ has kind ‘ETag -> *’ • In the first argument of ‘Exp’, namely ‘ext’ In the type ‘Exp ext’ In the definition of data constructor ‘Var’ | 17 | Var :: ext VarTag -> Exp ext | ^^^ Failed, 0 modules loaded. Prelude> }}} The type synonym can be inlined, makes no difference. -- Comment: Yes, I suppose that wouldn't be too hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 03:51:13 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 03:51:13 -0000 Subject: [GHC] #14514: Error messages: suggest annotating with higher-rank kind In-Reply-To: <051.b76142fd8282a689e3ab27ed27c38d69@haskell.org> References: <051.b76142fd8282a689e3ab27ed27c38d69@haskell.org> Message-ID: <066.08d66e3fa25b92c1d6574536705e9a68@haskell.org> #14514: Error messages: suggest annotating with higher-rank kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | TypeErrorMessages 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): * status: closed => new * resolution: invalid => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 08:58:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 08:58:01 -0000 Subject: [GHC] #14459: `make sdist-ghc` broken In-Reply-To: <042.28c91cc808d02e803cb2f4f0dc8cbb78@haskell.org> References: <042.28c91cc808d02e803cb2f4f0dc8cbb78@haskell.org> Message-ID: <057.c5edba4afd1659a50df2559d7cbfa522@haskell.org> #14459: `make sdist-ghc` broken -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.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 tdammers): I can reproduce the issue on a fresh checkout without overriding `$PATH`; just `./boot; ./configure; make sdist-ghc` is enough to trigger this exact error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 09:00:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 09:00:14 -0000 Subject: [GHC] #14527: Warn on recursive bindings In-Reply-To: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> References: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> Message-ID: <063.b75a005662eeb6ab380f0ca1a41bde02@haskell.org> #14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): Making it possible to have strict recursive bindings was by-design I believe, not accidental. Mostly, I think, for simplicity and uniformity rather than actual use-cases. More importantly, not every non-recursive binding should be strict! And putting a bang on every single non-recursive binding would indeed be tiresome. So coupling this warning business with bang patterns would be a mistake, I think. I rather like the idea of a tilde. It's allowed right now, but it's semantically a no-op. So using it as a per-binding way of disabling the warning would be quite neat. It's worth a proposal though. Make sure you handle recursive pattern bindings like {{{ (x,y) = f x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 09:05:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 09:05:25 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.700efe7fd6aaa9a3199ef1a2c2408de8@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): > I've got a patch committed that fixed some of that Oooh, yes please! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 09:07:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 09:07:11 -0000 Subject: [GHC] #14503: Killing a thread will block if there is another process reading from a handle In-Reply-To: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> References: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> Message-ID: <062.14b34f45b67256424a966d193618bb50@haskell.org> #14503: Killing a thread will block if there is another process reading from a handle -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dnadales): * component: Compiler => libraries/base Comment: The problem can be easily reproduced by running these two programs in parallel: {{{#!hs readWithinNSecs :: IO () readWithinNSecs = withSocketsDo $ do h <- connectTo "localhost" (PortNumber 9090) hSetBuffering h NoBuffering readerTid <- forkIO $ reader h threadDelay $ 2 * 10^6 putStrLn "Killing the reader" killThread readerTid putStrLn "Reader thread killed" where reader h = do line <- strip <$> hGetLine h putStrLn $ "Got " ++ line }}} {{{#!java import java.net.*; import java.io.*; public class Reader { public static void main(String[] args) throws IOException, InterruptedException { ServerSocket serverSock = new ServerSocket(9090); Socket sock = serverSock.accept(); InputStream inStream = sock.getInputStream(); BufferedReader sockIn = new BufferedReader(new InputStreamReader(inStream)); while (true) { Thread.sleep(1000); System.out.println("Trying to read something..."); String s = sockIn.readLine(); System.out.println("Got " + s ); } } } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 09:25:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 09:25:07 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.c17875f8b50c831a119ca8dca0c244f0@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by simonpj): I had a new idea: see Plan F in [wiki:ImplementingTreesThatGrow/Instances]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 12:48:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 12:48:14 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.206f755711a129da929e7946418d3050@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): I am not sure if I misunderstand Plan F, but GHC insists on a `Data` instance for the `x` in {{{#!hs newtype GhcExt x = Ext x instance (Data x) => Data (GhcExt x) where gmapM _f x = return x gunfold k z c = case constrIndex c of 1 -> k (z Ext) _ -> panic "GhcExt.gunfold" dataTypeOf _ = mkNoRepType "HsExtension.GhcExt" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 13:25:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 13:25:25 -0000 Subject: [GHC] #14529: Refactor ConDecl Message-ID: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> #14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 `ConDeclGADT` constructor in `ConDecl` is awful; all the information is buried. Refactor it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 13:31:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 13:31:40 -0000 Subject: [GHC] #14529: Refactor ConDecl In-Reply-To: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> References: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> Message-ID: <061.56389625f3c51fbc55f1114f802935b8@haskell.org> #14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 goldfire): Agreed, but don't use `LHsQTyVars`. This is used in `ConDeclH98`, but it shouldn't be. It should be a `[LHsTyVarBndr p]`. I've actually refactored this locally, but it's all tied up with my other very slowly-moving work. I haven't touched `ConDeclGADT` though, so by all means go ahead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 13:33:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 13:33:10 -0000 Subject: [GHC] #14530: hWaitForInput causes the program to abort on Windows Message-ID: <047.b2bc1211baaf66413ffab8f8c11dbb08@haskell.org> #14530: hWaitForInput causes the program to abort on Windows --------------------------------------+---------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- When running the following program on Windows (10): {{{#!hs readWithinNSecs :: IO () readWithinNSecs = withSocketsDo $ do h <- connectTo "localhost" (PortNumber 9090) hSetBuffering h NoBuffering readerTid <- forkIO $ politeReader h threadDelay (2 * 10^6) killThread readerTid where politeReader h = do info <- hShow h putStrLn info line <- ifM (hWaitForInput h (10^6)) (hGetLine h) (return "Nothing!") putStrLn $ "Got " ++ line }}} The program aborts with the following error: {{{#!text {loc=,type=duplex (read-write),buffering=none} fdReady: fd is too big This application has requested the Runtime to terminate it in an unusual way. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 13:35:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 13:35:49 -0000 Subject: [GHC] #14529: Refactor ConDecl In-Reply-To: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> References: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> Message-ID: <061.e818cf9d70201d4bb7d59e0364403f60@haskell.org> #14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): Here's what I have {{{ data ConDecl pass = ConDeclGADT { con_names :: [Located (IdP pass)] -- The next four fields describe the type after the '::' -- See Note [GADT abstract syntax] , con_forall :: Bool -- ^ True <=> explicit forall -- False => hsq_explicit is empty , con_qvars :: LHsQTyVars pass , con_mb_cxt :: Maybe (LHsContext pass) -- ^ User-written context (if any) , con_args :: HsConDeclDetails pass -- ^ Arguments; never InfixCon , con_res_ty :: LHsType pass -- ^ Result type , con_doc :: Maybe LHsDocString -- ^ A possible Haddock comment. } | ConDeclH98 { con_name :: Located (IdP pass) , con_forall :: Bool -- ^ True <=> explicit user-written forall -- e.g. data T a = forall b. MkT b (b->a) -- con_qvars = {b} -- False => hsq_implicit, hsq_explicit both empty , con_qvars :: LHsQTyVars pass -- Existentials only , con_mb_cxt :: Maybe (LHsContext pass) -- ^ User-written context (if any) , con_args :: HsConDeclDetails pass -- ^ Arguments , con_doc :: Maybe LHsDocString -- ^ A possible Haddock comment. } }}} `LHsQTYVars` seems right to me. I need those implicit binders. But not, I grant you, in the H98 case, because we never bind implicit variables there. I can change that too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 13:38:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 13:38:01 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.3d43c3015ac81d79c0c3cfd93f932843@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.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 AndreasK): Replying to [comment:38 saurabhnanda]: > Is there **any way** to enable callstacks without recompiling all your (transitive) dependencies? Currently it's implemented as a implicit parameter so I'm sure it would require recompilation. If you use profiled libraries maybe you could access CostCenter callstacks. But this provides less information and probably not what you want. Requiring recompilation seems like a reasonable limitation for such a functionality though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 14:22:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 14:22:06 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.452f3f56951b94bc8ee8ee90337a6eb2@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by simonpj): I was thinking abou this {{{ {-# LANGUAGE TypeFamilies, GADTs, FlexibleInstances, StandaloneDeriving, DeriveDataTypeable #-} module Foo where import Data.Data import Data.Typeable data Ext x = MkExt x data T a where MkT :: XT a -> a -> T a data GhcPass p type family XT a type instance XT (GhcPass p) = Ext () instance Typeable x => Data (Ext x) where gmapM f v = return v deriving instance Typeable p => Data (T (GhcPass p)) instance Typeable p => Data (GhcPass p) }}} This compiles fine. I regret the need for `Data (GhcPass p)`, becuase `(GhcPass p)` is ony a type index: there are no data values of this type. It's somehow needed in the defn of `gfoldl`, but I can't see why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 15:21:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 15:21:30 -0000 Subject: [GHC] #14483: getExecutablePath from System.Environment in base should follow symlinks properly. In-Reply-To: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> References: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> Message-ID: <062.8d4013b6e9b26b297d9f83ea154a0472@haskell.org> #14483: getExecutablePath from System.Environment in base should follow symlinks properly. -------------------------------------+------------------------------------- Reporter: angerman | Owner: alpmestan Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.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): D4227 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"62823668c48e13290e2ffe0d593a9f6a95cf628b/ghc" 62823668/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="62823668c48e13290e2ffe0d593a9f6a95cf628b" Follow symlinks in the Win32 code for System.Environment.getExecutablePath This partially addresses #14483 by fixing the Windows implementation of System.Environment.getExecutablePath. This is achieved by using GetFinalPathNameByHandleW to resolve potential symlinks, while making sure we do not get back a UNC path (see #14460). Test Plan: Validate Reviewers: Phyx, bgamari, angerman, hvr, goldfire Reviewed By: Phyx, bgamari GHC Trac Issues: #14483 Differential Revision: https://phabricator.haskell.org/D4227 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 15:21:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 15:21:30 -0000 Subject: [GHC] #14460: Symlink resolving fails against SMB mounts In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.429c53e6ac8005016ef1f5dc8a5c30bf@haskell.org> #14460: Symlink resolving fails against SMB mounts -------------------------------------+------------------------------------- Reporter: astert | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4216 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"62823668c48e13290e2ffe0d593a9f6a95cf628b/ghc" 62823668/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="62823668c48e13290e2ffe0d593a9f6a95cf628b" Follow symlinks in the Win32 code for System.Environment.getExecutablePath This partially addresses #14483 by fixing the Windows implementation of System.Environment.getExecutablePath. This is achieved by using GetFinalPathNameByHandleW to resolve potential symlinks, while making sure we do not get back a UNC path (see #14460). Test Plan: Validate Reviewers: Phyx, bgamari, angerman, hvr, goldfire Reviewed By: Phyx, bgamari GHC Trac Issues: #14483 Differential Revision: https://phabricator.haskell.org/D4227 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 15:24:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 15:24:21 -0000 Subject: [GHC] #14531: tcIfaceGlobal (local): not found Message-ID: <044.574a009d0a229a581813260133be5712@haskell.org> #14531: tcIfaceGlobal (local): not found --------------------------------------+--------------------------------- Reporter: bigos | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: Windows Msys2 | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I have installed Msys2 on Windows. In Msys2 I have installed Emacs, which I start with a custom cmd script with following environment variables set: {{{ SET PATH=C:\msys64\mingw64\bin;C:\msys64\usr\bin;%PATH% set XDG_DATA_DIRS=c:/msys64/mingw64/share set PKG_CONFIG_PATH=c:/msys64/mingw64/lib/pkgconfig set INCLUDE=c:/msys64/mingw64/include }}} The haskell I have is from Full Haskell Platform, https://haskell.org/platform/download/8.2.1/HaskellPlatform-8.2.1-full- x86_64-setup.exe Then I started eshell which I used to invoke this command: {{{ cabal install gi-gtk }}} Which after a while gave me following error. {{{ [91 of 95] Compiling GI.Pango.Objects.Layout ( GI\Pango\Objects\Layout.hs, dist\build\GI\Pango\Objects\Layout.o ) ghc.exe: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-mingw32): tcIfaceGlobal (local): not found You are in a maze of twisty little passages, all alike. While forcing the thunk for TyThing Layout which was lazily initialized by initIfaceCheck typecheckLoop, I tried to tie the knot, but I couldn't find Layout in the current type environment. If you are developing GHC, please read Note [Tying the knot] and Note [Type-checking inside the knot]. Consider rebuilding GHC with profiling for a better stack trace. Contents of current type environment: [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler\iface\TcIface.hs:1696:23 in ghc:TcIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Leaving directory 'C:\Users\Jacek\AppData\Local\Temp\cabal-tmp-8093 \gi-pango-1.0.15' Failed to install gi-gio-2.0.14 Build log ( C:\Users\Jacek\AppData\Roaming\cabal\logs\ghc-8.2.1\gi- gio-2.0.14-GKluzGq73QJBrHtRklhQDd.log ): Preprocessing library for gi-gio-2.0.14.. Building library for gi-gio-2.0.14.. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 15:37:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 15:37:03 -0000 Subject: [GHC] #14531: tcIfaceGlobal (local): not found In-Reply-To: <044.574a009d0a229a581813260133be5712@haskell.org> References: <044.574a009d0a229a581813260133be5712@haskell.org> Message-ID: <059.90a1fd37b4da7d37253b43aaab7d5cff@haskell.org> #14531: tcIfaceGlobal (local): not found ---------------------------------+-------------------------------------- Reporter: bigos | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Windows Msys2 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Description changed by bigos: Old description: > I have installed Msys2 on Windows. In Msys2 I have installed Emacs, which > I start with a custom cmd script with following environment variables > set: > > {{{ > SET PATH=C:\msys64\mingw64\bin;C:\msys64\usr\bin;%PATH% > > set XDG_DATA_DIRS=c:/msys64/mingw64/share > set PKG_CONFIG_PATH=c:/msys64/mingw64/lib/pkgconfig > set INCLUDE=c:/msys64/mingw64/include > }}} > > The haskell I have is from Full Haskell Platform, > https://haskell.org/platform/download/8.2.1/HaskellPlatform-8.2.1-full- > x86_64-setup.exe > > Then I started eshell which I used to invoke this command: > > {{{ > cabal install gi-gtk > }}} > > Which after a while gave me following error. > > {{{ > > [91 of 95] Compiling GI.Pango.Objects.Layout ( > GI\Pango\Objects\Layout.hs, dist\build\GI\Pango\Objects\Layout.o ) > ghc.exe: panic! (the 'impossible' happened) > (GHC version 8.2.1 for x86_64-unknown-mingw32): > tcIfaceGlobal (local): not found > You are in a maze of twisty little passages, all alike. > While forcing the thunk for TyThing Layout > which was lazily initialized by initIfaceCheck typecheckLoop, > I tried to tie the knot, but I couldn't find Layout > in the current type environment. > If you are developing GHC, please read Note [Tying the knot] > and Note [Type-checking inside the knot]. > Consider rebuilding GHC with profiling for a better stack trace. > Contents of current type environment: [] > Call stack: > CallStack (from HasCallStack): > prettyCurrentCallStack, called at > compiler\utils\Outputable.hs:1133:58 in ghc:Outputable > callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in > ghc:Outputable > pprPanic, called at compiler\iface\TcIface.hs:1696:23 in > ghc:TcIface > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > cabal: Leaving directory 'C:\Users\Jacek\AppData\Local\Temp\cabal- > tmp-8093\gi-pango-1.0.15' > Failed to install gi-gio-2.0.14 > Build log ( C:\Users\Jacek\AppData\Roaming\cabal\logs\ghc-8.2.1\gi- > gio-2.0.14-GKluzGq73QJBrHtRklhQDd.log ): > Preprocessing library for gi-gio-2.0.14.. > Building library for gi-gio-2.0.14.. > }}} New description: I have installed Msys2 on Windows. In Msys2 I have installed Emacs, which I start with a custom cmd script with following environment variables set: {{{ SET PATH=C:\msys64\mingw64\bin;C:\msys64\usr\bin;%PATH% set XDG_DATA_DIRS=c:/msys64/mingw64/share set PKG_CONFIG_PATH=c:/msys64/mingw64/lib/pkgconfig set INCLUDE=c:/msys64/mingw64/include }}} The haskell I have is from Full Haskell Platform, https://haskell.org/platform/download/8.2.1/HaskellPlatform-8.2.1-full- x86_64-setup.exe Then, within Emacs I have started eshell which I used to invoke this command: {{{ cabal install gi-gtk }}} Which after a while gave me following error. {{{ [91 of 95] Compiling GI.Pango.Objects.Layout ( GI\Pango\Objects\Layout.hs, dist\build\GI\Pango\Objects\Layout.o ) ghc.exe: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-mingw32): tcIfaceGlobal (local): not found You are in a maze of twisty little passages, all alike. While forcing the thunk for TyThing Layout which was lazily initialized by initIfaceCheck typecheckLoop, I tried to tie the knot, but I couldn't find Layout in the current type environment. If you are developing GHC, please read Note [Tying the knot] and Note [Type-checking inside the knot]. Consider rebuilding GHC with profiling for a better stack trace. Contents of current type environment: [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler\iface\TcIface.hs:1696:23 in ghc:TcIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Leaving directory 'C:\Users\Jacek\AppData\Local\Temp\cabal-tmp-8093 \gi-pango-1.0.15' Failed to install gi-gio-2.0.14 Build log ( C:\Users\Jacek\AppData\Roaming\cabal\logs\ghc-8.2.1\gi- gio-2.0.14-GKluzGq73QJBrHtRklhQDd.log ): Preprocessing library for gi-gio-2.0.14.. Building library for gi-gio-2.0.14.. }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 15:42:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 15:42:42 -0000 Subject: [GHC] #14527: Warn on recursive bindings In-Reply-To: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> References: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> Message-ID: <063.18878ed3e37fd55544e09756875252f4@haskell.org> #14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 nomeata): Just for clarification. Does > This applies to let, where and top-level pattern bindings. Mean it applies to {{{ let x = ones : x }}} and {{{ let f = \n -> if n == 0 then 1 else n * f (n-1) }}} but not {{{ let f n = if n == 0 then 1 else n * f (n-1) }}} right? (I think I like the explicit `~` on recursive value bindings.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 15:55:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 15:55:02 -0000 Subject: [GHC] #14511: indexArray# getting poorly deferred In-Reply-To: <046.562c7ba6b9fb319f3069f981d147d69c@haskell.org> References: <046.562c7ba6b9fb319f3069f981d147d69c@haskell.org> Message-ID: <061.a6b8c67ff53c6ab4df29eb079ee99e61@haskell.org> #14511: indexArray# getting poorly deferred -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 reinerp): Thanks Simon. I've worked around this with `{-# OPTIONS_GHC -fno-float-in #-}` on the relevant modules. Not important for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 16:01:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 16:01:03 -0000 Subject: [GHC] #14459: `make sdist-ghc` broken In-Reply-To: <042.28c91cc808d02e803cb2f4f0dc8cbb78@haskell.org> References: <042.28c91cc808d02e803cb2f4f0dc8cbb78@haskell.org> Message-ID: <057.96a0deef7f80c086f90e92ec7cb575f0@haskell.org> #14459: `make sdist-ghc` broken -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.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 tdammers): https://github.com/haskell/cabal/issues/4633 and https://github.com/haskell/cabal/commit/5e4f4d588 suggest that a pre- generated Lexer.hs is now committed to the Cabal repository, and Lexer.x has been moved outside the main source tree, the intention seems to be that alex is called manually, and that automated builds use the committed Lexer.hs directly. For now, simply skipping the explicit Alex step in ghc.mk seems to work fine, but as soon as Cabal adopts a more proper solution to the issue, we will probably have to cater for that and change things on our end as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 16:28:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 16:28:27 -0000 Subject: [GHC] #13110: GHC API allocates memory which is never GC'd In-Reply-To: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> References: <046.4f4fae4b39ad28415d63a3b9d1df9516@haskell.org> Message-ID: <061.5f7b73bf4524cae2d71263f8022688f1@haskell.org> #13110: GHC API allocates memory which is never GC'd -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.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 bgamari): Simon says that reverting CAFs will only revert CAFs in objects loaded by the runtime's linker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 16:28:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 16:28:45 -0000 Subject: [GHC] #14483: getExecutablePath from System.Environment in base should follow symlinks properly. In-Reply-To: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> References: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> Message-ID: <062.d04fd2559dd2de2111dac17deb755808@haskell.org> #14483: getExecutablePath from System.Environment in base should follow symlinks properly. -------------------------------------+------------------------------------- Reporter: angerman | Owner: alpmestan Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4227 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 16:28:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 16:28:52 -0000 Subject: [GHC] #14483: getExecutablePath from System.Environment in base should follow symlinks properly. In-Reply-To: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> References: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> Message-ID: <062.1466b2547c68b219a205e78c9bd6871a@haskell.org> #14483: getExecutablePath from System.Environment in base should follow symlinks properly. -------------------------------------+------------------------------------- Reporter: angerman | Owner: alpmestan Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4227 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 16:29:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 16:29:22 -0000 Subject: [GHC] #14459: `make sdist-ghc` broken In-Reply-To: <042.28c91cc808d02e803cb2f4f0dc8cbb78@haskell.org> References: <042.28c91cc808d02e803cb2f4f0dc8cbb78@haskell.org> Message-ID: <057.c84e2738c07892ab45470e61cb1a3811@haskell.org> #14459: `make sdist-ghc` broken -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Build System | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.1 Comment: We'll need this for 8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 16:32:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 16:32:54 -0000 Subject: [GHC] #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA In-Reply-To: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> References: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> Message-ID: <058.f4975801abdc4ac0a28c316bcb734dfb@haskell.org> #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | https://github.com/ntc2/ghc-8.2.1 | -regex-lazy-text-bug Blocked By: | Blocking: Related Tickets: #13745 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => tdammers * related: 13745 => #13745 * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 16:57:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 16:57:27 -0000 Subject: [GHC] #14449: Type variables allowed to unify in a partial type signature (PartialTypeSignatures) In-Reply-To: <047.c826e6c9d1aac2c5c605f0d32075e17d@haskell.org> References: <047.c826e6c9d1aac2c5c605f0d32075e17d@haskell.org> Message-ID: <062.0c5b98b5c5997ae6911797c6238c4432@haskell.org> #14449: Type variables allowed to unify in a partial type signature (PartialTypeSignatures) -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4efe5fed407067d4b27000e0cf4092cfb6f7502b/ghc" 4efe5fed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4efe5fed407067d4b27000e0cf4092cfb6f7502b" Check quantification for partial type signatues Trac #14449 showed that we were failing to check that the quantified type variables of a partial type signature remained distinct. See Note [Quantified variables in partial type signatures] in TcBinds. A little refactoring along the way. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 17:00:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 17:00:49 -0000 Subject: [GHC] #14449: Type variables allowed to unify in a partial type signature (PartialTypeSignatures) In-Reply-To: <047.c826e6c9d1aac2c5c605f0d32075e17d@haskell.org> References: <047.c826e6c9d1aac2c5c605f0d32075e17d@haskell.org> Message-ID: <062.6df490878e0fa96a66cc563dda51f17d@haskell.org> #14449: Type variables allowed to unify in a partial type signature (PartialTypeSignatures) -------------------------------------+------------------------------------- Reporter: kcsongor | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: partial- invalid program | sigs/should_fail/T14449 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => partial-sigs/should_fail/T14449 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 17:00:53 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 17:00:53 -0000 Subject: [GHC] #14532: Missing constant folding for Numeric.Natural Message-ID: <046.23ad3cef9c2f95ad9b5633c01b6d5e38@haskell.org> #14532: Missing constant folding for Numeric.Natural -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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 Haskell code {{{#!hs module Zero where import Numeric.Natural zero :: Natural zero = 0 }}} generates this Core: {{{#!hs -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} zero1 zero1 = 0 -- RHS size: {terms: 39, types: 12, coercions: 0, joins: 0/0} zero zero = case zero1 of { S# i#_a2c6 -> case tagToEnum# (>=# i#_a2c6 0#) of { False -> underflowError; True -> NatS# (int2Word# i#_a2c6) }; Jp# dt_a2cg -> case uncheckedIShiftRL# (sizeofByteArray# dt_a2cg) 3# of { __DEFAULT -> case sizeofByteArray# dt_a2cg of { __DEFAULT -> NatJ# dt_a2cg; 0# -> underflowError }; 1# -> case indexWordArray# dt_a2cg 0# of wild2_a2ck { __DEFAULT -> NatS# wild2_a2ck } }; Jn# ipv_a2cn -> underflowError } }}} It should instead generate this: {{{#!hs zero = NatS# 0## }}} This kind of code is generated whenever one uses `GHC.TypeLits.natVal`, even at a constant `Nat`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 17:05:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 17:05:32 -0000 Subject: [GHC] #14511: indexArray# getting poorly deferred In-Reply-To: <046.562c7ba6b9fb319f3069f981d147d69c@haskell.org> References: <046.562c7ba6b9fb319f3069f981d147d69c@haskell.org> Message-ID: <061.0a5c0564d1db863362b9c4ac35823904@haskell.org> #14511: indexArray# getting poorly deferred -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 17:24:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 17:24:14 -0000 Subject: [GHC] #14533: Make GHC more robust against PC crashes by using atomic writes Message-ID: <042.6f078c53750e85c0c893c4f87dfef677@haskell.org> #14533: Make GHC more robust against PC crashes by using atomic writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Yesterday my Windows machine crashed when ghc was building, left me with a lot of corrupted .hi files (and probably .o files as well). That made me think if we should change ghc to write its output with atomic moves. Discussion on `#ghc`: {{{ bgamari: nh2: well, perhaps I'm not sure it's terribly common for compilers to take such precautions though and if we were to do it for interface files then presumably we would also want to do it for object files siarheit_: that would be very nice geekosaur: compilers in general are happy to write out incomplete/garbage object files bgamari: it seems that way nh2: bgamari: right, if we wanted to do it we should do it for all files ghc writes. Possible that other compilers can also write garbage, but maybe ghc can do better -- one less thing the developer has to think about Phyx-: most compilers also don't do the aggressive recompilation avoidance things we do either.. corrupt hi files wouldn't be an issue if the next time it would override them :) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 17:24:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 17:24:38 -0000 Subject: [GHC] #14533: Make GHC more robust against PC crashes by using atomic writes In-Reply-To: <042.6f078c53750e85c0c893c4f87dfef677@haskell.org> References: <042.6f078c53750e85c0c893c4f87dfef677@haskell.org> Message-ID: <057.d25f2c8cf8b48740c2b44430ab3491f0@haskell.org> #14533: Make GHC more robust against PC crashes by using atomic writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * component: Compiler => Build System -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 17:53:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 17:53:21 -0000 Subject: [GHC] #14532: Missing constant folding for Numeric.Natural In-Reply-To: <046.23ad3cef9c2f95ad9b5633c01b6d5e38@haskell.org> References: <046.23ad3cef9c2f95ad9b5633c01b6d5e38@haskell.org> Message-ID: <061.1c235fb8f63d1749bde9807b95570271@haskell.org> #14532: Missing constant folding for Numeric.Natural -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14170 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14170 Comment: Thanks for the bug report. This is a duplicate of #14170, so I'll close this ticket in favor of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 18:07:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 18:07:52 -0000 Subject: [GHC] #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA In-Reply-To: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> References: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> Message-ID: <058.0a6aa5a1ecd1afdded1551219b6fc386@haskell.org> #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | https://github.com/ntc2/ghc-8.2.1 | -regex-lazy-text- | bug/tree/07b7bb32c6e90e8f2d2eada4b59943f37e632d53 Blocked By: | Blocking: Related Tickets: #13745 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ntc2): * testcase: https://github.com/ntc2/ghc-8.2.1-regex-lazy-text-bug => https://github.com/ntc2/ghc-8.2.1-regex-lazy-text- bug/tree/07b7bb32c6e90e8f2d2eada4b59943f37e632d53 Old description: > When using `Text.RE.TDFA` from the regex-tdfa package on GHC 8.2 to match > trivial regexes against `Data.Text.Lazy` strings, I see **exponential > runtime**. On GHC 8.0, or using `Data.Text` strict strings or `String` > strings, the runtime is as expected. > > Here's my repo with simple test code illustrating the regression and > timing stats: https://github.com/ntc2/ghc-8.2.1-regex-lazy-text-bug. > > In summary, for the problematic combination of GHC version and libraries, > the run times are 3s, 10s, 22s, and 40s > for counting regex matches in files with 10000, > 20000, 30000, and 40000 lines, respectively. For all of the > unproblematic combinations -- i.e. GHC 8.0.2, `String`, strict > `Data.Text`, or building with profiling -- the run time is always about > 1s! > > And **this is a Heisenbug**, in that the performance problem goes away if > I build with profiling support! > > There is the separate Issue #13745 about **compile-time regressions** in > GHC 8.2 + the regex-tdfa package, that > [https://ghc.haskell.org/trac/ghc/ticket/13745#comment:18 I commented > on]. New description: When using `Text.RE.TDFA` from the regex-tdfa package on GHC 8.2 to match trivial regexes against `Data.Text.Lazy` strings, I see **exponential runtime**. On GHC 8.0, or using `Data.Text` strict strings or `String` strings, the runtime is as expected. Here's my repo with simple test code illustrating the regression and timing stats: https://github.com/ntc2/ghc-8.2.1-regex-lazy-text- bug/tree/07b7bb32c6e90e8f2d2eada4b59943f37e632d53 . In summary, for the problematic combination of GHC version and libraries, the run times are 3s, 10s, 22s, and 40s for counting regex matches in files with 10000, 20000, 30000, and 40000 lines, respectively. For all of the unproblematic combinations -- i.e. GHC 8.0.2, `String`, strict `Data.Text`, or building with profiling -- the run time is always about 1s! And **this is a Heisenbug**, in that the performance problem goes away if I build with profiling support! There is the separate Issue #13745 about **compile-time regressions** in GHC 8.2 + the regex-tdfa package, that [https://ghc.haskell.org/trac/ghc/ticket/13745#comment:18 I commented on]. -- Comment: I'm having trouble with the bisection search because `hashable` won't build on some intermediate dev GHCs I've tried. I tried changing the test case to use `regex-tdfa-text`+`Data.Text.Lazy` directly, instead of via the common interface provided by `regex`, but then the problem goes away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 18:27:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 18:27:56 -0000 Subject: [GHC] #14533: Make GHC more robust against PC crashes by using atomic writes In-Reply-To: <042.6f078c53750e85c0c893c4f87dfef677@haskell.org> References: <042.6f078c53750e85c0c893c4f87dfef677@haskell.org> Message-ID: <057.b6110356b46ac4e5d33d034a1ca637d2@haskell.org> #14533: Make GHC more robust against PC crashes by using atomic writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): I'm not sure if I understand "atomic writes" here correctly, but e.g. on POSIX systems there is not really much "atomic" regarding I/O. One of the few things is renaming a file, but even that is not atomic depending on the underlying file system (e.g. NFS and/or SMB IIRC). So I think the best a compiler can do is to write its file under a fresh name next to its destination, and rename it when it completed writing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 18:30:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 18:30:03 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.206c1194d31a84ae09ed55027dd42931@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.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): It's not an entirely trivial task. We use uniques quite often to name symbols in code produced by the native codegen. Fixing this without compromising compiler performance is rather tricky. I don't know if niteria has thought much about how to approach this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 18:40:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 18:40:20 -0000 Subject: [GHC] #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: In-Reply-To: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> References: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> Message-ID: <060.74753760b41bbcf8a8177710a8f5e482@haskell.org> #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: -------------------------------------+------------------------------------- Reporter: slyfox | Owner: angerman Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => angerman Comment: Has this been fixed, angerman? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 18:40:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 18:40:30 -0000 Subject: [GHC] #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: In-Reply-To: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> References: <045.3936f21bdd3848870db3bf9280c23e0a@haskell.org> Message-ID: <060.9a0126c38545b2e36f840b306dc0d4a4@haskell.org> #14261: ghc stopped recognizing some arm triplets that used to work: Failed to lookup the datalayout for armv7a-hardfloat-linux-gnueabi; available targets: -------------------------------------+------------------------------------- Reporter: slyfox | Owner: angerman Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 18:41:14 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 18:41:14 -0000 Subject: [GHC] #14533: Make GHC more robust against PC crashes by using atomic writes In-Reply-To: <042.6f078c53750e85c0c893c4f87dfef677@haskell.org> References: <042.6f078c53750e85c0c893c4f87dfef677@haskell.org> Message-ID: <057.0f241bd1144a6009336c06c14ffe2d30@haskell.org> #14533: Make GHC more robust against PC crashes by using atomic writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > So I think the best a compiler can do is to write its file under a fresh name next to its destination, and rename it when it completed writing it. Indeed, I believe this is what nh2 was suggesting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 18:45:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 18:45:35 -0000 Subject: [GHC] #14503: Killing a thread will block if there is another process reading from a handle In-Reply-To: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> References: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> Message-ID: <062.6a2d622d5378f80aa033661d168269c1@haskell.org> #14503: Killing a thread will block if there is another process reading from a handle -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks for the repro! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 19:39:18 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 19:39:18 -0000 Subject: [GHC] #14503: Killing a thread will block if there is another process reading from a handle In-Reply-To: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> References: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> Message-ID: <062.0fe5b2bc0cee9aeb3ccde7cb1cf071de@haskell.org> #14503: Killing a thread will block if there is another process reading from a handle -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is an complete all-Haskell repro, {{{#!hs -- Server.hs import System.IO import Network import Control.Monad import Control.Concurrent main = withSocketsDo $ do sock <- listenOn $ PortNumber 9090 (h, _, _) <- accept sock forever $ do threadDelay 100000 putStrLn "Trying to read something" s <- hGetLine h putStrLn $ "Got "++s }}} {{{#!hs -- Client.hs import Network import System.IO import Control.Concurrent main = readWithinNSecs readWithinNSecs :: IO () readWithinNSecs = withSocketsDo $ do h <- connectTo "localhost" (PortNumber 9090) hSetBuffering h NoBuffering readerTid <- forkIO $ reader h threadDelay $ 2 * 10^6 putStrLn "Killing the reader" killThread readerTid putStrLn "Reader thread killed" where reader h = do line <- hGetLine h putStrLn $ "Got " ++ line }}} Expected output (as seen on Debian 9 with GHC 8.2.2), {{{ $ ghc Server.hs $ ghc Client.hs $ ./Server & ./Client Trying to read something Killing the reader Reader thread killed Server: : hGetLine: end of file }}} Observed output (on Windows 10 with 64-bit GHC 8.2.1), {{{ $ ghc Server.hs $ ghc -threaded Client.hs $ ./Server & ./Client Killing the reader Reader thread killed Trying to read something server.exe: : hGetLine: failed (Unknown error) }}} Seems like things are working as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 19:46:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 19:46:35 -0000 Subject: [GHC] #14503: Killing a thread will block if there is another process reading from a handle In-Reply-To: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> References: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> Message-ID: <062.43d76d367f7e57451e06375261d06232@haskell.org> #14503: Killing a thread will block if there is another process reading from a handle -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 Comment: Ahh, but indeed it hangs when `Client` is built with 8.0.2. It looks like this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 19:47:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 19:47:38 -0000 Subject: [GHC] #14503: Killing a thread will block if there is another process reading from a handle In-Reply-To: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> References: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> Message-ID: <062.280521836be85347d882fc477f87124c@haskell.org> #14503: Killing a thread will block if there is another process reading from a handle -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Windows | 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: Unfortunately it's not entirely clear how to add a testcase for this as it seems to require a socket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 22:40:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 22:40:12 -0000 Subject: [GHC] #14534: Split T12971 into its own Makefile Message-ID: <045.dc9d469c7c661699270f66b7951e0a7a@haskell.org> #14534: Split T12971 into its own Makefile -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: low | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `testsuite/tests/driver/Makefile` includes the `T12971` target. This (intentionally) has non-ASCII characters in it. As a result, any change to that makefile will trigger a lint error. We should give that test its own makefile to isolate it a bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 23:29:03 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 23:29:03 -0000 Subject: [GHC] #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): stack depth overflow Message-ID: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64 -apple-darwin): stack depth overflow -------------------------------------+------------------------------------- Reporter: iTotallyExist | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1 Keywords: panic! stack | Operating System: MacOS X depth overflow | Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I created a neural network library within haskell. I was able to create, test, and train the net (using data from the mNist dataset). I could only test manually (try one input at a time and compare the two outputs), so i made a function which allowed me to test many test inputs on the net at once. Recreating bug: first, load main.hs in ghci (duh) then, run the entirety of trainedNetwork.txt as a command to initialise the network (i.e. copy paste the file into the ghci command line) then run the entirety of test.txt as a command. Here you will get the error. To test with different input values for the function "test" (the function whose being run caused the crash), you can open the jupyter notebook and run the function mnistTest with higher or lower values (higher using more test cases, lower using less) and run the output of that function as a command in haskell. (i know from testing that 30 inputs does not cause a crash, but 50 does). What i know is not the problem/probably causes: I know that y was initiliased correctly. The function being run here is : {{{#!hs --takes in a network and an array of test inputs and their corresponding outputs and returns the accuracy of the network --only works for classification networks testClassification :: [Layer] -> [[Double]] -> [[Double]] -> Double testClassification net inputs outputs = testClassificationHelper net inputs outputs 0 0 testClassificationHelper :: [Layer] -> [[Double]] -> [[Double]] -> Double -> Double -> Double testClassificationHelper _ [] _ correct incorrect = (correct/(correct+incorrect)) testClassificationHelper net (input:inputs) (output:outputs) correct incorrect | netMax == outMax = next (correct+1) incorrect | otherwise = next correct (incorrect+1) where next = testClassificationHelper net inputs outputs netMax = greatestIndex (getOutput net input) outMax = greatestIndex output }}} I know that getOutput and greatestIndex work\\ I know that it works with a small amount of inputs (test3.txt is essentially the same command except instead of using the first 100 test examples of the mnist data set, it uses the first 3)\\ I know that it works when using the first 30 data points, but not with the first 50.\\ I know that doing it for the first 30 inputs only takes 2 seconds and 270 MB, while training the network took 40 minutes and 820GB, take from that what you will\\ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 23:30:55 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 23:30:55 -0000 Subject: [GHC] #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): stack depth overflow In-Reply-To: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> References: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> Message-ID: <067.34c705a7913f527a009f2e3399fb71a4@haskell.org> #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64 -apple-darwin): stack depth overflow -------------------------------------+------------------------------------- Reporter: iTotallyExist | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: panic! stack | depth overflow Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by iTotallyExist): * Attachment "main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 23:31:45 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 23:31:45 -0000 Subject: [GHC] #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): stack depth overflow In-Reply-To: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> References: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> Message-ID: <067.fd1e94849502e7a730473007f3838f5b@haskell.org> #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64 -apple-darwin): stack depth overflow -------------------------------------+------------------------------------- Reporter: iTotallyExist | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: panic! stack | depth overflow Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by iTotallyExist): * Attachment "test3.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 23:32:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 23:32:42 -0000 Subject: [GHC] #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): stack depth overflow In-Reply-To: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> References: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> Message-ID: <067.17f295c248161efb65b2d03bf370e8c0@haskell.org> #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64 -apple-darwin): stack depth overflow -------------------------------------+------------------------------------- Reporter: iTotallyExist | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: panic! stack | depth overflow Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by iTotallyExist): * Attachment "test.zip" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 23:32:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 23:32:56 -0000 Subject: [GHC] #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): stack depth overflow In-Reply-To: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> References: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> Message-ID: <067.c691814e1f645e521792f51a8853d5ac@haskell.org> #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64 -apple-darwin): stack depth overflow -------------------------------------+------------------------------------- Reporter: iTotallyExist | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: panic! stack | depth overflow Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by iTotallyExist): * Attachment "test command generator.ipynb" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 27 23:46:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Nov 2017 23:46:37 -0000 Subject: [GHC] #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): stack depth overflow In-Reply-To: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> References: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> Message-ID: <067.7b8f7360cf759d9dc3809a22d885ac32@haskell.org> #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64 -apple-darwin): stack depth overflow -------------------------------------+------------------------------------- Reporter: iTotallyExist | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: panic! stack | depth overflow Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by iTotallyExist: Old description: > I created a neural network library within haskell. I was able to create, > test, and train the net (using data from the mNist dataset). I could > only test manually (try one input at a time and compare the two outputs), > so i made a function which allowed me to test many test inputs on the net > at once. > > Recreating bug: > first, load main.hs in ghci (duh) > then, run the entirety of trainedNetwork.txt as a command to initialise > the network (i.e. copy paste the file into the ghci command line) > then run the entirety of test.txt as a command. Here you will get the > error. > To test with different input values for the function "test" (the function > whose being run caused the crash), you can open the jupyter notebook and > run the function mnistTest with higher or lower values (higher using more > test cases, lower using less) and run the output of that function as a > command in haskell. (i know from testing that 30 inputs does not cause a > crash, but 50 does). > > What i know is not the problem/probably causes: > I know that y was initiliased correctly. > The function being run here is : > {{{#!hs > --takes in a network and an array of test inputs and their corresponding > outputs and returns the accuracy of the network > --only works for classification networks > testClassification :: [Layer] -> [[Double]] -> [[Double]] -> Double > testClassification net inputs outputs = testClassificationHelper net > inputs outputs 0 0 > > testClassificationHelper :: [Layer] -> [[Double]] -> [[Double]] -> Double > -> Double -> Double > testClassificationHelper _ [] _ correct incorrect = > (correct/(correct+incorrect)) > testClassificationHelper net (input:inputs) (output:outputs) correct > incorrect | netMax == outMax = next (correct+1) incorrect > | otherwise = next correct (incorrect+1) > where > next = testClassificationHelper net inputs outputs > netMax = greatestIndex (getOutput net input) > outMax = greatestIndex output > }}} > I know that getOutput and greatestIndex work\\ > I know that it works with a small amount of inputs (test3.txt is > essentially the same command except instead of using the first 100 test > examples of the mnist data set, it uses the first 3)\\ > I know that it works when using the first 30 data points, but not with > the first 50.\\ > I know that doing it for the first 30 inputs only takes 2 seconds and 270 > MB, while training the network took 40 minutes and 820GB, take from that > what you will\\ New description: I created a neural network library within haskell. I was able to create, test, and train the net (using data from the mNist dataset). I could only test manually (try one input at a time and compare the two outputs), so i made a function which allowed me to test many test inputs on the net at once. Recreating bug: first, load main.hs in ghci (duh) then, run the entirety of trainedNetwork.txt as a command to initialise the network (i.e. copy paste the file into the ghci command line) then run the entirety of test.txt as a command. Here you will get the error. To test with different input values for the function "test" (the function whose being run caused the crash), you can open the jupyter notebook and run the function mnistTest with higher or lower values (higher using more test cases, lower using less) and run the output of that function as a command in haskell. (i know from testing that 41 inputs does not cause a crash, but 42 does (seriously, this is not a joke)) . What i know is not the problem/probably causes: I know that y was initiliased correctly. The function being run here is : {{{#!hs --takes in a network and an array of test inputs and their corresponding outputs and returns the accuracy of the network --only works for classification networks testClassification :: [Layer] -> [[Double]] -> [[Double]] -> Double testClassification net inputs outputs = testClassificationHelper net inputs outputs 0 0 testClassificationHelper :: [Layer] -> [[Double]] -> [[Double]] -> Double -> Double -> Double testClassificationHelper _ [] _ correct incorrect = (correct/(correct+incorrect)) testClassificationHelper net (input:inputs) (output:outputs) correct incorrect | netMax == outMax = next (correct+1) incorrect | otherwise = next correct (incorrect+1) where next = testClassificationHelper net inputs outputs netMax = greatestIndex (getOutput net input) outMax = greatestIndex output }}} I know that getOutput and greatestIndex work\\ I know that it works with a small amount of inputs (test3.txt is essentially the same command except instead of using the first 100 test examples of the mnist data set, it uses the first 3)\\ I know that it works when using the first 30 data points, but not with the first 50.\\ I know that doing it for the first 30 inputs only takes 2 seconds and 270 MB, while training the network took 40 minutes and 820GB, take from that what you will\\ -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 01:29:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 01:29:45 -0000 Subject: [GHC] #14459: `make sdist-ghc` broken In-Reply-To: <042.28c91cc808d02e803cb2f4f0dc8cbb78@haskell.org> References: <042.28c91cc808d02e803cb2f4f0dc8cbb78@haskell.org> Message-ID: <057.d652f58945aea6938f6e11dc5cb4bfb5@haskell.org> #14459: `make sdist-ghc` broken -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Build System | Version: 8.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 Ben Gamari ): In [changeset:"eb86e867694bceedfb47a527d71429197ffe6dda/ghc" eb86e867/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eb86e867694bceedfb47a527d71429197ffe6dda" Don't call alex for Cabal lib during GHC build The Cabal library now commits `Lexer.hs` directly to the source tree, so the build step where we'd call alex ourselves to generate that file is no longer necessary, nor will it work. See also: https://ghc.haskell.org/trac/ghc/ticket/14459 Reviewers: bgamari, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14459 Differential Revision: https://phabricator.haskell.org/D4240 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 01:29:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 01:29:45 -0000 Subject: [GHC] #14516: getGCStats was broken in 8.2 In-Reply-To: <048.f2f53ed169f1f3d9dc0f869cb0501a1f@haskell.org> References: <048.f2f53ed169f1f3d9dc0f869cb0501a1f@haskell.org> Message-ID: <063.028ac3541ab04329e9a1125f3aa62a2c@haskell.org> #14516: getGCStats was broken in 8.2 -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: libraries/base | Version: 8.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 Ben Gamari ): In [changeset:"54fda257d4a7bfddaa0c1fa0be698d1a849c4124/ghc" 54fda257/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="54fda257d4a7bfddaa0c1fa0be698d1a849c4124" base: Rip out old RTS statistics interface Test Plan: Validate Reviewers: simonmar, hvr Subscribers: rwbarton, thomie GHC Trac Issues: #14516 Differential Revision: https://phabricator.haskell.org/D4228 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 01:37:54 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 01:37:54 -0000 Subject: [GHC] #14529: Refactor ConDecl In-Reply-To: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> References: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> Message-ID: <061.6091acbb81fbcb489462fc799033550a@haskell.org> #14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 goldfire): The problem with `LHsQTyVars` is that every other instance of that type stores the user-written tyvars of a tycon declaration. Thus, the `kcHsTyVarBndrs` function that checks them asks for information about CUSKs, etc., which is utterly wrong for data constructors. (The reason I refactored this is that I've had to make some changes to `kcHsTyVarBndrs` in my type-level implication constraints patch, such that it no longer works at all for datacons.) Really, the right type for GADT constructors is `HsImplicitBndrs`. The problem is that you'd then have to have a tiered structure, where a `ConDeclGADT` stores an `HsImplicitBndrs` wrapped around a `ConDeclGADTDetails` or some such. It's a bit ugly. But the structure would be just right. Alternatives would be to have a `con_implicit_qvars :: [IdP pass], con_explicit_qvars :: [LHsTyVarBndr pass]`, or a new function to consume a `LHsQTyVars` from a datacon (instead of `kcHsTyVarBndrs`). Also, why change the `Maybe ...` to a `Bool` (with an invariant) to say whether or not there's a forall? The `Maybe` seems closer to the truth. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 02:01:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 02:01:25 -0000 Subject: [GHC] #2401: aborting an STM transaction should throw an exception In-Reply-To: <043.102536ca2a3e567cb6677ad0a9004c1b@haskell.org> References: <043.102536ca2a3e567cb6677ad0a9004c1b@haskell.org> Message-ID: <058.912732d9c6a0122e8cc0d686fc2dbeda@haskell.org> #2401: aborting an STM transaction should throw an exception -------------------------------------+------------------------------------- Reporter: sclv | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 03:13:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 03:13:25 -0000 Subject: [GHC] #14516: getGCStats was broken in 8.2 In-Reply-To: <048.f2f53ed169f1f3d9dc0f869cb0501a1f@haskell.org> References: <048.f2f53ed169f1f3d9dc0f869cb0501a1f@haskell.org> Message-ID: <063.0b67cf96c66d9b1ebc56d278a9be0ed8@haskell.org> #14516: getGCStats was broken in 8.2 -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 8.2.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: 8.2.3 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 05:07:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 05:07:08 -0000 Subject: [GHC] #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): stack depth overflow In-Reply-To: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> References: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> Message-ID: <067.92d25a319e74a453d79cc8c47934fbcc@haskell.org> #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64 -apple-darwin): stack depth overflow -------------------------------------+------------------------------------- Reporter: iTotallyExist | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: panic! stack | depth overflow Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by iTotallyExist: Old description: > I created a neural network library within haskell. I was able to create, > test, and train the net (using data from the mNist dataset). I could > only test manually (try one input at a time and compare the two outputs), > so i made a function which allowed me to test many test inputs on the net > at once. > > Recreating bug: > first, load main.hs in ghci (duh) > then, run the entirety of trainedNetwork.txt as a command to initialise > the network (i.e. copy paste the file into the ghci command line) > then run the entirety of test.txt as a command. Here you will get the > error. > To test with different input values for the function "test" (the function > whose being run caused the crash), you can open the jupyter notebook and > run the function mnistTest with higher or lower values (higher using more > test cases, lower using less) and run the output of that function as a > command in haskell. (i know from testing that 41 inputs does not cause a > crash, but 42 does (seriously, this is not a joke)) . > > What i know is not the problem/probably causes: > I know that y was initiliased correctly. > The function being run here is : > {{{#!hs > --takes in a network and an array of test inputs and their corresponding > outputs and returns the accuracy of the network > --only works for classification networks > testClassification :: [Layer] -> [[Double]] -> [[Double]] -> Double > testClassification net inputs outputs = testClassificationHelper net > inputs outputs 0 0 > > testClassificationHelper :: [Layer] -> [[Double]] -> [[Double]] -> Double > -> Double -> Double > testClassificationHelper _ [] _ correct incorrect = > (correct/(correct+incorrect)) > testClassificationHelper net (input:inputs) (output:outputs) correct > incorrect | netMax == outMax = next (correct+1) incorrect > | otherwise = next correct (incorrect+1) > where > next = testClassificationHelper net inputs outputs > netMax = greatestIndex (getOutput net input) > outMax = greatestIndex output > }}} > I know that getOutput and greatestIndex work\\ > I know that it works with a small amount of inputs (test3.txt is > essentially the same command except instead of using the first 100 test > examples of the mnist data set, it uses the first 3)\\ > I know that it works when using the first 30 data points, but not with > the first 50.\\ > I know that doing it for the first 30 inputs only takes 2 seconds and 270 > MB, while training the network took 40 minutes and 820GB, take from that > what you will\\ New description: I created a neural network library within haskell. I was able to create, test, and train the net (using data from the mNist dataset). I could only test manually (try one input at a time and compare the two outputs), so i made a function which allowed me to test many test inputs on the net at once. Recreating bug: first, load main.hs in ghci (duh) then, run the entirety of trainedNetwork.txt as a command to initialise the network (i.e. copy paste the file into the ghci command line) then run the entirety of test.txt as a command. Here you will get the error. To test with different input values for the function "test" (the function whose being run caused the crash), you can open the jupyter notebook and run the function mnistTest with higher or lower values (higher using more test cases, lower using less) and run the output of that function as a command in haskell. (i know from testing that 41 inputs does not cause a crash, but 42 does (seriously, this is not a joke)) . What i know is not the problem/probably causes: I know that y was initiliased correctly. The function being run here is : {{{#!hs --takes in a network and an array of test inputs and their corresponding outputs and returns the accuracy of the network --only works for classification networks testClassification :: [Layer] -> [[Double]] -> [[Double]] -> Double testClassification net inputs outputs = testClassificationHelper net inputs outputs 0 0 testClassificationHelper :: [Layer] -> [[Double]] -> [[Double]] -> Double -> Double -> Double testClassificationHelper _ [] _ correct incorrect = (correct/(correct+incorrect)) testClassificationHelper net (input:inputs) (output:outputs) correct incorrect | netMax == outMax = next (correct+1) incorrect | otherwise = next correct (incorrect+1) where next = testClassificationHelper net inputs outputs netMax = greatestIndex (getOutput net input) outMax = greatestIndex output }}} I know that getOutput and greatestIndex work\\ I know that it works with a small amount of inputs (test3.txt is essentially the same command except instead of using the first 100 test examples of the mnist data set, it uses the first 3)\\ I know that it works when using the first 30 data points, but not with the first 50.\\ I know that doing it for the first 30 inputs only takes 2 seconds and 270 MB, while training the network took 40 minutes and 820GB, take from that what you will\\ Note: trainedNetwork.txt is too large to upload, so it is available at https://drive.google.com/open?id=1HfCNknZ9AfJauQoNwzhlEwsQfcHTya0t -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 05:40:33 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 05:40:33 -0000 Subject: [GHC] #14536: Ghc panics while building stage2 with -dstg-lint Message-ID: <043.07052cd8274441bc63c2d750cdfb2370@haskell.org> #14536: Ghc panics while building stage2 with -dstg-lint -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- Building ghc at 54fda257d4a7bfddaa0c1fa0be698d1a849c4124 with the following mk/build.mk: {{{ BuildFlavour = validate ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif GhcStage2HcOpts += -dcore-lint -dstg-lint -dcmm-lint }}} building with: {{{ make compiler/stage2/build/Exception.o }}} panics with: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.3.20171127 for x86_64-unknown-linux): ASSERT failed! dataConInstArgTys Unit# [k0_10, a_11] ['TupleRep '[], 'IntRep, State# RealWorld, Int#] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1208:22 in ghc:Outputable assertPprPanic, called at compiler/basicTypes/DataCon.hs:1256:76 in ghc:DataCon Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1206:5 in ghc:Outputable assertPprPanic, called at compiler/basicTypes/DataCon.hs:1256:76 in ghc:DataCon Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Once this is resolved, is there any reason that -dstg-ling and -dcmm-lint are not set on validate (at least with SLOW)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 08:40:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 08:40:03 -0000 Subject: [GHC] #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.fe80258adc38ec6be0db0c721554dbef@haskell.org> #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by OlivierSohn): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 08:42:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 08:42:13 -0000 Subject: [GHC] #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.4b634469fdf8075dd36d99f12ac350b3@haskell.org> #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by OlivierSohn): I raised the priority as this bug it prevents me from refactoring code because I need constantly to make sure that the bug is not happening again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 09:07:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 09:07:31 -0000 Subject: [GHC] #14527: Warn on recursive bindings In-Reply-To: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> References: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> Message-ID: <063.b074dcd14c8b311b765dc4d999f651db@haskell.org> #14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 chrisdone): I think there's a spanner in the works because {{{ print = \case ... App f x -> print f <> " " <> print x }}} is a common idiomatic way of writing functions these days. We wouldn't want a warning for that. So I'm afraid it's less straight-forward than I hoped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 09:37:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 09:37:57 -0000 Subject: [GHC] #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.cbb1ed93ab7c6218310d7d3f81a2a590@haskell.org> #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): That looks like a good minimal example but you still have lots of unnecessary dependencies in the cabal file. Unless the project can be compiled with a single invocation of ghc or cabal then it is unlikely someone will make quick progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 09:57:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 09:57:13 -0000 Subject: [GHC] #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match In-Reply-To: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> References: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> Message-ID: <065.e7291a5a16db127a475e2ba606754338@haskell.org> #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match -------------------------------------+------------------------------------- Reporter: BoteboTsebo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lippling): I think this is not fixed completely. With 8.2.2 I get: {{{ [62 of 63] Compiling Handler.Arena ( Handler/Arena.hs, .stack- work/dist/x86_64-osx/Cabal-2.0.1.0/build/Handler/Arena.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-apple-darwin): isStrictPattern Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Disabling ApplicativeDo helps. I don't know what triggers it, yet. If you need to know, I'll try to find a minimal example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 10:15:34 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 10:15:34 -0000 Subject: [GHC] #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.a4f3a597ab984739e0f72f42e817d752@haskell.org> #14521: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by OlivierSohn): @mpickering Thanks for the feedback, so now I removed all dependencies from the cabal file. I also found out that if the Animation module is entirely exported : {{{ module Animation where }}} It fixes the problem! I added this observation in the comments. Here is the branch : https://github.com/OlivierSohn/hamazed/tree/repro- ghc-14521-A -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 10:19:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 10:19:14 -0000 Subject: [GHC] #14521: Infinite loop at runtime (was: Infinite loop at runtime when either : a given function is not marked INLINE, or functions are stored in strict field) In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.d36b648eb433181181ad457fa1e0bd66@haskell.org> #14521: Infinite loop at runtime -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by OlivierSohn): I rename the title because there are actually more ways to circumvent the problem, which are all documented in the code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 10:20:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 10:20:41 -0000 Subject: [GHC] #14497: internal error: scavenge_one: strange object 19828 In-Reply-To: <044.d9e9a438baea314f437751a66a161d85@haskell.org> References: <044.d9e9a438baea314f437751a66a161d85@haskell.org> Message-ID: <059.dde53ccf767c11ad2146041e3813701c@haskell.org> #14497: internal error: scavenge_one: strange object 19828 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: bgamari => simonmar Comment: I think this is a simple fix, patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 10:35:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 10:35:27 -0000 Subject: [GHC] #14527: Warn on recursive bindings In-Reply-To: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> References: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> Message-ID: <063.bf05893de462398e640e5389ec89110d@haskell.org> #14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): > So I'm afraid it's less straight-forward than I hoped. It's only a warning so it's ok to have ad-hoc (but still well specified) conditions. For example: you get a warning if * The binding is recursive (or part of a recursive group) * It is a pattern or simple variable binding; that is there are no argument on the LHS * The LHS does not have a top-level tilde * The RHS is not a syntactic value. Then define syntactic values to be: literal, constructor application, lambda, `\case`, etc. (This is the slightly ad-hoc bit.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 10:36:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 10:36:41 -0000 Subject: [GHC] #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match In-Reply-To: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> References: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> Message-ID: <065.dc3e366f7f6a0b7b878f2161c85d894a@haskell.org> #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match -------------------------------------+------------------------------------- Reporter: BoteboTsebo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ugh. Yes a minimal test case would be super helpful. Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 11:08:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 11:08:43 -0000 Subject: [GHC] #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match In-Reply-To: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> References: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> Message-ID: <065.6daa249ca73302628f0d0b2986c8428f@haskell.org> #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match -------------------------------------+------------------------------------- Reporter: BoteboTsebo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by BoteboTsebo): @lipping I believe it is still broken in 8.2.2 since it hasn't been merged in, since it lacks a test case. I am not sure how test cases work in GHC, thus I don't have the confidence that I could create one myself. I'll look around for a few fixed bugs and see how their test cases were structured, and hopefully (very unlikely with my current knowledge) come up with a commit or two to complete this fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 12:19:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 12:19:44 -0000 Subject: [GHC] #14521: Infinite loop at runtime In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.e9d8fdac86be2caddcf32a8fdb121363@haskell.org> #14521: Infinite loop at runtime -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > Hello, > > in https://github.com/OlivierSohn/hamazed/issues/1 I describe the > following issue: > > **(Edit : the same behaviour exists with ghc 8.2.2)** > > When compiling on OSX with optimizations (`stack clean && stack build` > using resolver `lts-9.12` (ghc 8.0.2)), the program loops infinitely > (400% CPU, and execution is blocked) when an animation is triggered in > the game. When compiling without optimizations, there is not this bug. > > The bug is visible in the full game at this commit : > https://github.com/OlivierSohn/hamazed/commit/9f25223ef0502f91cd9633654bdb172f714c3920 > (to reproduce, shoot at a number in the game) > > And this commit shows a program with minimal code to reproduce the issue > : > https://github.com/OlivierSohn/hamazed/commit/30b0f703565a4150d686a36a4dfe9d36ce5989f1 > > The expected output of the program is > > {{{ > Before rendering animations > animation is rendered > After rendering animations > }}} > > What I observe is > > {{{ > Before rendering animations > }}} > > I found several ways to circumvent the problem, wrote them in the code to > help debugging. > > Also, here is my stack version if it matters: > {{{ > stack version: `1.3.2, Git revision > 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 > hpack-0.15.0` > }}} > > Thank you, > Olivier New description: Hello, For this program : https://github.com/OlivierSohn/hamazed/tree/repro- ghc-14521-A The expected output is: {{{ Before rendering animations animation is rendered After rendering animations }}} What I observe is when compiling with ghc 8.0.2 or 8.2.2, with optimizations: {{{ Before rendering animations }}} I found several ways to circumvent the bug, and documented each one in the source code. Can someone take a look? Is my program an invalid program that was not detected by the compiler? Thank you, Olivier -- Comment (by OlivierSohn): I update the description to reference the branch of the repro case and not a particular commit, and to be more concise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 12:43:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 12:43:35 -0000 Subject: [GHC] #14521: Infinite loop at runtime In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.fce3c0f6efbdf12935ccee4d420ac6ea@haskell.org> #14521: Infinite loop at runtime -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 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 OlivierSohn): * os: MacOS X => Unknown/Multiple Comment: I verified I can reproduce it on OS X and Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 14:42:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 14:42:31 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll Message-ID: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> #14537: Do not link to msvcrt.dll ------------------------------------------+---------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Linking) | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------------------+---------------------------- msvcrt is a system component and you can't depend on it, it should be either msvcrVERSION.dll if you're using dynamic linkage or nothing if you're using static. https://social.msdn.microsoft.com/Forums/vstudio/en-us/2203f72c- 5f09-4565-97b3-21337672b191/msvcrtdll?forum=vcgeneral More against msvcrt: https://sourceforge.net/p/mingw-w64/wiki2/The%20case%20against%20msvcrt.dll/ GCC solution: http://www.mingw.org/node/25#comment-106 (not sure if it is relevant here) P.S. I am not user of GHC, I am just using one application written in Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 15:26:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 15:26:09 -0000 Subject: [GHC] #14527: Warn on recursive bindings In-Reply-To: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> References: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> Message-ID: <063.cf64c1ee29c4b1b595c6643ba82cc9bd@haskell.org> #14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 goldfire): So, `ones = 1 : ones` wouldn't be warned? I suppose that's OK, but I would prefer that such a definition is indeed warned (without a `~`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 15:42:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 15:42:10 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.302c1b244ac20303d812cd98160609d9@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Phyx- (added) Comment: Thanks for bringing this up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 15:50:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 15:50:31 -0000 Subject: [GHC] #14459: `make sdist-ghc` broken In-Reply-To: <042.28c91cc808d02e803cb2f4f0dc8cbb78@haskell.org> References: <042.28c91cc808d02e803cb2f4f0dc8cbb78@haskell.org> Message-ID: <057.e830fbef6ca95b2b92e1b53cab903c6a@haskell.org> #14459: `make sdist-ghc` broken -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Build System | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I have verified that `sdist-ghc` works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 16:14:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 16:14:21 -0000 Subject: [GHC] #14521: Infinite loop at runtime In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.1c014f77605e682afac538c9ef9f921a@haskell.org> #14521: Infinite loop at runtime -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 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): For the record, I am seeing the program loop in `Animation_zdwanimatedNumber_info`. Indeed looking at the simplified Core, the "bad" configuration compiles to {{{#!hs -- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} Animation.$wanimatedNumber [InlPrag=[0], Occ=LoopBreaker] :: GHC.Prim.Int# -> Tree -> Animation -> IO (Maybe Animation) [GblId, Arity=1, Caf=NoCafRefs, Str=b] Animation.$wanimatedNumber = \ (ww_s3v3 :: GHC.Prim.Int#) -> Animation.$wanimatedNumber ww_s3v3 end Rec } }}} Bad news bears. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 16:45:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 16:45:23 -0000 Subject: [GHC] #14521: Infinite loop at runtime In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.b23ac95b97d3566c6b48ed5f0b81e463@haskell.org> #14521: Infinite loop at runtime -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Resolution: invalid | 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): * status: new => closed * resolution: => invalid Comment: So I'm not certain why the program runs successfully without optimization, but it seems to me like the compiler indeed loop. The gist of the program (eliminating some irrelevant bits) is {{{#!hs data Animator a = Animator { _animatorIO :: !(Tree -> Animation -> IO (Maybe Animation)) } mkAnimator :: (t -> Tree -> Animation -> IO (Maybe Animation)) -> t -> Animator a mkAnimator io_ params = Animator (io_ params) animatedNumber :: Int -> Tree -> Animation -> IO (Maybe Animation) animatedNumber n = animate' (mkAnimator animatedNumber n) }}} After inlining `mkAnimator` into `animatedNumber` and expressing the constructor's strictness explicitly we have, {{{#!hs animatedNumber :: Int -> Tree -> Animation -> IO (Maybe Animation) animatedNumber n = animate' (let x = animatedNumber n in x `seq` Animator x) }}} Consequently if `animate'` demands its argument the program will loop. This function is defined as, {{{#!hs animate' :: Animator a -> Tree -> Animation -> IO (Maybe Animation) animate' (Animator pure_ io_) = animate pure_ io_ }}} Which indeed does demand its argument. Moreover, this is consistent with your observation that adding an `INLINE` on `animate'` eliminates the loop (since in the real program `Animator` contains two fields, only the first, which I elided above, is needed). Given this, it seems like looping is a completely valid compilation of this program. I would remove the bang from the constructor if laziness is needed (which it seems it is). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 16:46:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 16:46:41 -0000 Subject: [GHC] #14527: Warn on recursive bindings In-Reply-To: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> References: <048.ff3ef128d39fbc9b303ca6b6013599d0@haskell.org> Message-ID: <063.415be67c85df67e3fac34e7fec921e68@haskell.org> #14527: Warn on recursive bindings -------------------------------------+------------------------------------- Reporter: chrisdone | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 chrisdone): Right, I was aiming for {{{ones = 1 : ones}}} to be a warning. How about we rephrase it as "function-like": * The RHS is not a function-like: either a lambda or a lambda-case. (If the RHS is a literal then by-definition it's not recursive and wouldn't trigger the warning, I think.) With an ad-hoc bit like that, I'm more convinced that this could be practical. I'll consider making a proposal for it. A draft implementation could be run against Stackage to see how many false-positives it flags up. Here and reddit provided enough concerns -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 16:47:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 16:47:01 -0000 Subject: [GHC] #14533: Make GHC more robust against PC crashes by using atomic writes In-Reply-To: <042.6f078c53750e85c0c893c4f87dfef677@haskell.org> References: <042.6f078c53750e85c0c893c4f87dfef677@haskell.org> Message-ID: <057.3dbfebe117d1fa4469784af8e898a235@haskell.org> #14533: Make GHC more robust against PC crashes by using atomic writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Yes, I had the rename method in mind. If the underlying FS can't do atomic renames, then all bets are off and we've done the best we could. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 17:02:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 17:02:32 -0000 Subject: [GHC] #14521: Infinite loop at runtime In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.57d597a95905c4b86bb19ca625bfc16e@haskell.org> #14521: Infinite loop at runtime -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Resolution: invalid | 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 simonpj): I took a quick look. To me it looks as if it should definitely loop. Look at the code {{{ animatedNumber n = animate' (mkAnimator animateNumberPure animatedNumber n) mkAnimator pure_ io_ params = Animator (applyAnimation (pure_ params)) (io_ params) animate' (Animator pure_ io_) = animate pure_ io_ }}} If we just inline `mkAnimator` we see: {{{ animatedNumber n = animate' (Animator blah (animatedNumber n)) }}} Now * `Aminator` is declared to be strict in its second argument * `animate'` is certainly strict So of course `animatedNumber n` will just return bottom. The mystery is not why it diverges -- it should! -- but rather why it sometimes fails to diverge. The answer is that GHC allows itself a bit of leeway in making a divergent program into one that converges, in the interests of improving runtimes generally by allowing more optimisations. You can switch off this behaviour by using `-fpedantic-bottoms`, and then sure enough it always diverges. In this case the relevant optimisation is eta-expansion. If you do manual eta-expansion on `animate'`, then it converges, always: {{{ animate' :: Animator a -> Tree -> Animation -> IO (Maybe Animation) animate' (Animator pure_ io_) t a = animate pure_ io_ t a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 17:09:42 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 17:09:42 -0000 Subject: [GHC] #14538: forkprocess01 fails occassionally on with multiple ACQUIRE_LOCK panic Message-ID: <046.6179459a606dda455f09a96c2a4bfb98@haskell.org> #14538: forkprocess01 fails occassionally on with multiple ACQUIRE_LOCK panic ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.1 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 noticed that `forkprocess01` failed to build on Darwin and commit eb86e867694bceedfb47a527d71429197ffe6dda with {{{ Stderr ( forkprocess01 ): forkprocess01: internal error: multiple ACQUIRE_LOCK: rts/Task.c 228 (GHC version 8.3.20171128 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug /bin/sh: line 1: 5124 Abort trap: 6 ./forkprocess01 +RTS -ls -RTS *** unexpected failure for forkprocess01(threaded1_ls) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 17:10:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 17:10:26 -0000 Subject: [GHC] #14538: forkprocess01 fails occassionally on with multiple ACQUIRE_LOCK panic In-Reply-To: <046.6179459a606dda455f09a96c2a4bfb98@haskell.org> References: <046.6179459a606dda455f09a96c2a4bfb98@haskell.org> Message-ID: <061.a75a74aee9ce61abaf9fd6a15ab04b72@haskell.org> #14538: forkprocess01 fails occassionally on with multiple ACQUIRE_LOCK panic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.3 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 bgamari): * version: 8.2.1 => 8.3 Comment: Since this appears to be OS X-specific I suspect this is due to the `ITimer.c` implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 17:34:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 17:34:51 -0000 Subject: [GHC] #14536: Ghc panics while building stage2 with -dstg-lint In-Reply-To: <043.07052cd8274441bc63c2d750cdfb2370@haskell.org> References: <043.07052cd8274441bc63c2d750cdfb2370@haskell.org> Message-ID: <058.7dec8a81090a5b760f869bc97f3d4ae6@haskell.org> #14536: Ghc panics while building stage2 with -dstg-lint -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): Humph. The 'unarise' pass, which is performed on STG, also transforms types. In this case we transform {{{ case getMaskingState# eta of x { (# a, b #) -> blah ===> case getMaskingState# eta of x { Unit# a -> blah -- Unit# is really a one-tuple (# a #) }}} Here we eliminate the void field (the state token). But that changes the type of the scrutinee; but we don't in fact change the type of the case-binder `x`; and that in turn leads to the crash. It's not very convenient to get hold of `x`'s new type; and in any case `x` is guaranteed to be dead. So it seems hardly worth writing more code. Lets either * Simply drop the lint check (in `litAlt`, don't call `dataConInstArgTys`); or * Make the case-binder into a `Maybe` and only check its type when it's a `Just`. I suspect that the former is simpler for now; do leave a comment to link to this ticket though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 17:42:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 17:42:03 -0000 Subject: [GHC] #14536: Ghc panics while building stage2 with -dstg-lint In-Reply-To: <043.07052cd8274441bc63c2d750cdfb2370@haskell.org> References: <043.07052cd8274441bc63c2d750cdfb2370@haskell.org> Message-ID: <058.f78a524236ea0b0b62aa0408e2175a99@haskell.org> #14536: Ghc panics while building stage2 with -dstg-lint -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: stg-lint 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): * keywords: => stg-lint -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 17:42:20 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 17:42:20 -0000 Subject: [GHC] #14116: STG lint error while compiling master In-Reply-To: <046.64b3c05e81659fe1cbefd837174d080f@haskell.org> References: <046.64b3c05e81659fe1cbefd837174d080f@haskell.org> Message-ID: <061.cf3dc9a4007ac80029ee4cafb05bc239@haskell.org> #14116: STG lint error while compiling master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: stg-lint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3856 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => stg-lint -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 17:43:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 17:43:01 -0000 Subject: [GHC] #13994: STG lint failure on master In-Reply-To: <046.5016d5ec5ebb8180ad382ac86e8db74e@haskell.org> References: <046.5016d5ec5ebb8180ad382ac86e8db74e@haskell.org> Message-ID: <061.d7cca925ce1e102447a622ae40d28219@haskell.org> #13994: STG lint failure on master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: stg-lint 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): * keywords: => stg-lint -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 17:43:03 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 17:43:03 -0000 Subject: [GHC] #14120: Type comparison in stg-lint is hopelessly broken In-Reply-To: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> References: <046.97e3cbd3c7067720bbd928fabe1980e0@haskell.org> Message-ID: <061.b7ab824de51b78312e904b20ab85365e@haskell.org> #14120: Type comparison in stg-lint is hopelessly broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: stg-lint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3879 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => stg-lint -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 17:49:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 17:49:01 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.4f007e47617a5a65b3223382653d9ad4@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): There are two separate things going on here. 1. Where are the implicitly-added foralls? Example {{{ f :: forall (a :: j). Int -> forall (b :: k). MyProxy a }}} This is short for {{{ f :: forall {j,k}. forall (a :: j). Int -> forall (b :: k). MyProxy a }}} That is, implicit foralls are added at the top (only). The `forall b` stays where it is, of course. 2. What type variables are lexically scoped? Once we have {{{ f :: forall {j,k}. forall (a :: j). Int -> forall (b :: k). MyProxy a }}} which variables are in scope? Presumably `a` and `j`. But the choice to bring `k` into scope is less obvious. Apparently it is. Arguably it should not be. But what about {{{ f2 :: forall a. forall b. blah f3 :: forall a. Ord a => forall b. blah }}} For these, should `b` scope over the body of `f`? That's the debate in #14288. For pattern synonyms, the answers may differ. 1. Where are the implicitly-added foralls? Example {{{ pattern SS :: forall (t :: k'). () => forall (a :: kk -> k') (n :: kk). (t ~ a n) => blah }}} This is short for {{{ pattern SS :: forall {k'}. forall (t :: k'). () => forall {kk}. forall (a :: kk -> k') (n :: kk). (t ~ a n) => blah }}} Notice that the `forall {kk}` is nested: `kk` is existential according to our rules. This is annoying. I'm not arguing for a particular outcome, just pointing out that there are two issues, best discussed separately. Let's not discuss implementation until we have a design! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 18:23:31 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 18:23:31 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.267190a129bb3e48c927b3e17ce88ac3@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => invalid Comment: Yes, MSVCRT IS a system component, and that is EXACTLY why you can depend on it being available. It is the only C runtime you can guarantee to be available on every version of Windows. Which is why we and GCC link against it by default. Historically (up until Vista) the Windows Driver Toolkits used their own compilers which linked against msvcrt as well. This to provide a backwards compatible way to write drivers and other system utilities. That is not to say the msvcrt.dll in Windows today is the same as it was before. It gets patched quite often. You have misunderstood the links you provided. The first off, the numbered versions are a component of the newer Visual Studio C++ Runtimes. Hence the versions. Each release is tied directly to a visual studio release. We do not have the rights to redistribute these files, so we cannot link against them by default. Also we don't know which one is available to use so portable distributions will not work. This is why applications compiled with Visual Studio typically *need* an installer. This would break workflows such as stack based ones, and require admin rights to install GHC. Your second link says this clearly at the top: {{{ Historically, Windows ports of gcc have used Microsoft's msvcrt.dll as the only available C runtime. This is not necessarily a bad idea, as it considerably simplifies deployment, and it gives gcc-compiled application the classical UNIX guarantee that all code in a given process shares the same version and instance of the C runtime library. However, the use of msvcrt.dll in Windows ports of gcc (Cygwin first, then MinGW) came with a large number of misconceptions. This article will attempt to correct them. }}} The MingW compilers use `msvcrt.dll` by default. Your third link even shows this. If you still don't believe that, this is the GCC source code for the mingw32 backend https://github.com/gcc- mirror/gcc/blob/trunk/gcc/config/i386/mingw32.h#L142 We do not rely on the runtime for newer functionaly (such as C99 functions). We explicitly link against `libmingwex` for this exact reason. However we still need to link against the runtime to get basic things like `malloc`. Just like GCC, your own applications don't have to depend on this. We use GCC for the final compilation, so the exact same workaround GCC uses can be used for your own programs. e.g. you have to provide GCC with a custom SPEC file to tell it what you want to link against. You however cannot get GHCi to do this, since we load system libraries which have a transitive dependency on msvcrt. And you can't mix and match these libraries as each contain different allocators. Lastly: {{{ it should be either msvcrVERSION.dll if you're using dynamic linkage or nothing if you're using static. }}} Is wrong. See https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx You always need a C runtime. for static linking with Microsoft compilers when you specify `/MT` (e.g. static linking) you get `libcmt.lib` linked in, which is the static version of the runtime. Dynamic linking `/MD` gets you `msvcrt.lib` which is an import library pointing to the appropriate version of the numbered msvcrt. However, again we compile with GCC which does not provide a statically linked runtime for Windows. (GLIBC doesn't work on Windows). And unless we switch our compiler to the Microsoft ones we cannot use the ones distributed with the compilers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 18:31:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 18:31:49 -0000 Subject: [GHC] #14539: untouchable type inside the constraints Message-ID: <046.e791a4fd7c5c8d50126f67c9980c3ee6@haskell.org> #14539: untouchable type inside the constraints -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code is taken and simplified from the test-suite of `accelerate-fourier`: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE Rank2Types #-} module UntouchableType (tests) where import Test.QuickCheck (Testable, Arbitrary, arbitrary, quickCheck, ) newtype Sign a = Sign a deriving (Show) instance Arbitrary (Sign a) where arbitrary = undefined quickCheckWithSign :: (Testable prop) => (Sign Double -> prop) -> IO () quickCheckWithSign = quickCheck data Array sh a = Array type family FullShape sh :: * data SubTransform a = SubTransform (forall sh. (FullShape sh ~ sh) => Array sh a) transform2d :: SubTransform Double -> Bool transform2d = undefined transformChirp2 :: Sign a -> Array sh a transformChirp2 = undefined tests :: IO () tests = quickCheck $ \sign -> transform2d (SubTransform (transformChirp2 (sign::Sign Double))) }}} GHC-8.2.2 says about it: {{{ [1 of 1] Compiling UntouchableType ( UntouchableType.hs, interpreted ) UntouchableType.hs:34:4: error: • Ambiguous type variable ‘p0’ arising from a use of ‘quickCheck’ prevents the constraint ‘(Arbitrary p0)’ from being solved. Probable fix: use a type annotation to specify what ‘p0’ should be. These potential instances exist: instance (Arbitrary a, Arbitrary b) => Arbitrary (Either a b) -- Defined in ‘Test.QuickCheck.Arbitrary’ instance Arbitrary Ordering -- Defined in ‘Test.QuickCheck.Arbitrary’ instance Arbitrary Integer -- Defined in ‘Test.QuickCheck.Arbitrary’ ...plus 20 others ...plus 62 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the expression: quickCheck $ \ sign -> transform2d (SubTransform (transformChirp2 (sign :: Sign Double))) In an equation for ‘tests’: tests = quickCheck $ \ sign -> transform2d (SubTransform (transformChirp2 (sign :: Sign Double))) | 34 | quickCheck $ \sign -> | ^^^^^^^^^^^^^^^^^^^^^... UntouchableType.hs:35:51: error: • Couldn't match expected type ‘Sign Double’ with actual type ‘p0’ ‘p0’ is untouchable inside the constraints: FullShape sh ~ sh bound by a type expected by the context: forall sh. FullShape sh ~ sh => Array sh Double at UntouchableType.hs:35:20-69 • In the first argument of ‘transformChirp2’, namely ‘(sign :: Sign Double)’ In the first argument of ‘SubTransform’, namely ‘(transformChirp2 (sign :: Sign Double))’ In the first argument of ‘transform2d’, namely ‘(SubTransform (transformChirp2 (sign :: Sign Double)))’ • Relevant bindings include sign :: p0 (bound at UntouchableType.hs:34:18) | 35 | transform2d (SubTransform (transformChirp2 (sign::Sign Double))) | ^^^^ Failed, no modules loaded. }}} I have tested GHC versions back to GHC-7.4.2, all of them report essentially the same type error. I do not really understand the type error message, but here are my observations that I find strange: The type annotation `sign :: Sign Double` does not prevent the type error, but replacing `quickCheck` by `quickCheckWithSign` does. Replacing the constraint `FullShape sh ~ sh` by, e.g. `Show sh`, let the error disappear. Generalizing `transform2d` to `SubTransform a` causes another type error although I expected that `SubTransform Double` can be infered from `Sign Double`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 18:33:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 18:33:55 -0000 Subject: [GHC] #14540: IndexError: pop from empty list Message-ID: <046.d5b9a5e6c04c98d634ef1167801af522@haskell.org> #14540: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: Lemming | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.2.1 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: -------------------------------------+------------------------------------- ==== How to Reproduce ==== While doing a GET operation on `/attachment/ticket/14539/`, Trac issued an internal error. ''(please provide additional details here)'' Request parameters: {{{ {u'action': u'new', 'path': u'14539/', 'realm': u'ticket'} }}} User agent: `#USER_AGENT#` ==== System Information ==== ''Systeminformation nicht verfügbar'' ==== Enabled Plugins ==== ''Plugininformation nicht verfügbar'' ==== Interface Customization ==== ''Interface customization information not available'' ==== Python Traceback ==== {{{ Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/trac/web/main.py", line 623, in _dispatch_request dispatcher.dispatch(req) File "/usr/local/lib/python2.7/dist-packages/trac/web/main.py", line 259, in dispatch iterable=chrome.use_chunked_encoding) File "/usr/local/lib/python2.7/dist-packages/trac/web/chrome.py", line 1165, in render_template encoding='utf-8') File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 184, in render return encode(generator, method=method, encoding=encoding, out=out) File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 58, in encode for chunk in iterator: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 350, in __call__ for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 829, in __call__ for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 669, in __call__ for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 774, in __call__ for kind, data, pos in chain(stream, [(None, None, None)]): File "/usr/local/lib/python2.7/dist-packages/genshi/output.py", line 594, in __call__ for ev in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/trac/web/chrome.py", line 1432, in _strip_accesskeys for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/trac/web/chrome.py", line 1421, in _generate for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 706, in _unmark for mark, event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 1101, in __call__ for mark, event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 118, in __iter__ event = self.stream.next() File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 734, in __call__ for mark, event in stream: File "/usr/local/lib/python2.7/dist- packages/genshi/filters/transform.py", line 702, in _mark for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 378, in _match ctxt, start=idx + 1, **vars): File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 378, in _match ctxt, start=idx + 1, **vars): File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 362, in _match content = list(content) File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 326, in _match for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip event = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/path.py", line 588, in _generate subevent = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip event = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/core.py", line 289, in _ensure for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/path.py", line 588, in _generate subevent = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 618, in _include for event in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/template/markup.py", line 315, in _strip event = next() File "/usr/local/lib/python2.7/dist-packages/genshi/template/base.py", line 558, in _flatten for kind, data, pos in stream: File "/usr/local/lib/python2.7/dist-packages/genshi/filters/i18n.py", line 178, in _generate for event in msgbuf.translate(gettext(msgbuf.format())): File "/usr/local/lib/python2.7/dist-packages/genshi/filters/i18n.py", line 1051, in translate events = self.events[order].pop(0) IndexError: pop from empty list }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 19:32:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 19:32:38 -0000 Subject: [GHC] #14521: Infinite loop at runtime In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.280b205d61b186f2b2e53435144941f3@haskell.org> #14521: Infinite loop at runtime -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Resolution: invalid | 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 OlivierSohn): Replying to [comment:21 simonpj]: > In this case the relevant optimisation is eta-expansion. If you do manual eta-expansion on > `animate'`, then it converges, always: > {{{ > animate' :: Animator a -> Tree -> Animation -> IO (Maybe Animation) > animate' (Animator pure_ io_) t a = animate pure_ io_ t a > }}} Thank you for your analysis, I think I understand why making the record field non-strict fixes the problem, but I don't understand why the eta- expansion also fixes it, could you explain me or point me to a resource explaining this point? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 19:45:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 19:45:47 -0000 Subject: [GHC] #14521: Infinite loop at runtime In-Reply-To: <050.17f0ae18f3e58888a2116da899248456@haskell.org> References: <050.17f0ae18f3e58888a2116da899248456@haskell.org> Message-ID: <065.42cd039900b5fe706b95015bda099f06@haskell.org> #14521: Infinite loop at runtime -------------------------------------+------------------------------------- Reporter: OlivierSohn | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.2 Resolution: invalid | 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 OlivierSohn): Replying to [comment:20 bgamari]: Thanks for your explanations! I'm not used to think in term of strict / lazy evaluation so I'll need to re-read them a few times until I understand everything :) As a default I was told to use strict fields to avoid accumulating thunks, and it's the first time I encounter a problem where I actually need lazyness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 19:53:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 19:53:38 -0000 Subject: [GHC] #14123: Figure out invariants surrounding ticks in Core In-Reply-To: <046.0308c769b363c5285c5969fe8d556b65@haskell.org> References: <046.0308c769b363c5285c5969fe8d556b65@haskell.org> Message-ID: <061.01ce849e4cc169dad57e3afd9e646dfb@haskell.org> #14123: Figure out invariants surrounding ticks in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13233, #14122, | Differential Rev(s): #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #13233, #142122, #8472, #14406 => #13233, #14122, #8472, #14406 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 19:54:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 19:54:52 -0000 Subject: [GHC] #14118: Strangeness regarding STG alternative types and linter In-Reply-To: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> References: <046.fe51086ace7a694923ce20b260d9c0a1@haskell.org> Message-ID: <061.161946d15ca9276061b1f9d8711572a2@haskell.org> #14118: Strangeness regarding STG alternative types and linter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: stg-lint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3889 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => stg-lint -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 19:55:02 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 19:55:02 -0000 Subject: [GHC] #14117: stg-lint fails on unlifted-type join point binding In-Reply-To: <046.0674e9c956dcac2c07b3c9b8cffe8c8f@haskell.org> References: <046.0674e9c956dcac2c07b3c9b8cffe8c8f@haskell.org> Message-ID: <061.e5de268ae97955f46ef914dfcf35dadb@haskell.org> #14117: stg-lint fails on unlifted-type join point binding -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: stg-lint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3857 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => stg-lint -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 19:55:16 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 19:55:16 -0000 Subject: [GHC] #13941: STG linter's type equality can loop In-Reply-To: <046.4184638e601895ab74015b9135b0dc45@haskell.org> References: <046.4184638e601895ab74015b9135b0dc45@haskell.org> Message-ID: <061.5750b2e802b70bc60e6f691927c63144@haskell.org> #13941: STG linter's type equality can loop -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: fixed | Keywords: stg-lint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => stg-lint -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 19:57:58 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 19:57:58 -0000 Subject: [GHC] #14536: Ghc panics while building stage2 with -dstg-lint In-Reply-To: <043.07052cd8274441bc63c2d750cdfb2370@haskell.org> References: <043.07052cd8274441bc63c2d750cdfb2370@haskell.org> Message-ID: <058.1931774bb1501c934d8b6a09a1de98bc@haskell.org> #14536: Ghc panics while building stage2 with -dstg-lint -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: stg-lint 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 duog): * owner: (none) => duog Comment: Thanks, I'll see if I can fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 20:52:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 20:52:50 -0000 Subject: [GHC] #14221: yaml-0.8.23.3 fails to build with -g In-Reply-To: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> References: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> Message-ID: <061.4cf06f423b0c0110966ca80e8df685c8@haskell.org> #14221: yaml-0.8.23.3 fails to build with -g -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.2.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:D3977 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"048a91380cbbc18d1704bb7c328247a1660b5596/ghc" 048a913/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="048a91380cbbc18d1704bb7c328247a1660b5596" cmm: Use LocalBlockLabel instead of AsmTempLabel to represent blocks blockLbl was originally changed in 8b007abbeb3045900a11529d907a835080129176 to use mkTempAsmLabel to fix an inconsistency resulting in #14221. However, this breaks the C code generator, which doesn't support AsmTempLabels (#14454). Instead let's try going the other direction: use a new CLabel variety, LocalBlockLabel. Then we can teach the C code generator to deal with these as well. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 20:52:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 20:52:50 -0000 Subject: [GHC] #14454: Unregisterised build is broken In-Reply-To: <046.16eab3f0c63c2818b23a6ad81d240445@haskell.org> References: <046.16eab3f0c63c2818b23a6ad81d240445@haskell.org> Message-ID: <061.cbf7cba2739578f1eaabd1b816471391@haskell.org> #14454: Unregisterised build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.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 Ben Gamari ): In [changeset:"048a91380cbbc18d1704bb7c328247a1660b5596/ghc" 048a913/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="048a91380cbbc18d1704bb7c328247a1660b5596" cmm: Use LocalBlockLabel instead of AsmTempLabel to represent blocks blockLbl was originally changed in 8b007abbeb3045900a11529d907a835080129176 to use mkTempAsmLabel to fix an inconsistency resulting in #14221. However, this breaks the C code generator, which doesn't support AsmTempLabels (#14454). Instead let's try going the other direction: use a new CLabel variety, LocalBlockLabel. Then we can teach the C code generator to deal with these as well. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 20:52:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 20:52:50 -0000 Subject: [GHC] #14454: Unregisterised build is broken In-Reply-To: <046.16eab3f0c63c2818b23a6ad81d240445@haskell.org> References: <046.16eab3f0c63c2818b23a6ad81d240445@haskell.org> Message-ID: <061.c31087579036ae7546c138176ef760ef@haskell.org> #14454: Unregisterised build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.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 Ben Gamari ): In [changeset:"d3b80c79c2f906cd05066c374f4f19392033dfea/ghc" d3b80c79/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d3b80c79c2f906cd05066c374f4f19392033dfea" Cmm: Add missing cases for BlockInfoTable Silly rabbit, BlockInfoTables are data. This fixes the unregisterised build, finally fixing #14454. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 20:54:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 20:54:41 -0000 Subject: [GHC] #14454: Unregisterised build is broken In-Reply-To: <046.16eab3f0c63c2818b23a6ad81d240445@haskell.org> References: <046.16eab3f0c63c2818b23a6ad81d240445@haskell.org> Message-ID: <061.02bec334c39cf992484b68637f5c3e38@haskell.org> #14454: Unregisterised build is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I believe this should now be resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 21:00:44 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 21:00:44 -0000 Subject: [GHC] #14541: Stg lint failure while building ghc-stage2: compiler/stage2/build/Hoopl/Block.o Message-ID: <043.cd9c2f13d20866525a2d25a84f929b95@haskell.org> #14541: Stg lint failure while building ghc-stage2: compiler/stage2/build/Hoopl/Block.o -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- With the tree at: https://github.com/duog/ghc/tree/trac-14536 Which fixes ticket:14536 With build.mk: {{{ BuildFlavour = validate ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif GhcStage2HcOpts += -dcore-lint -dstg-lint -dcmm-lint }}} building with: {{{ make compiler/stage2/build/Hoopl/Blocks.o }}} I get the following Stg lint error (extracts, full dump attached): {{{ : warning: [in body of lambda with binders ds_s4dH :: a_a3as -> b_a3at, ds1_s4dI :: MaybeO ex_a3ao a_a3as] In some algebraic case alternative, number of arguments doesn't match constructor: JustO (arity 2) [a1_s4dK] }}} ... {{{ $fFunctorMaybeO_$cfmap :: forall ex a b. (a -> b) -> MaybeO ex a -> MaybeO ex b [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=OtherCon []] = [] \r [ds_s4dH ds1_s4dI] case ds1_s4dI of { JustO a1_s4dK [Occ=Once] -> let { sat_s4dL [Occ=Once] :: b_a3at [LclId] = [ds_s4dH a1_s4dK] \u [] ds_s4dH a1_s4dK; } in JustO [sat_s4dL]; NothingO -> $WNothingO; }; }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 21:01:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 21:01:57 -0000 Subject: [GHC] #14541: Stg lint failure while building ghc-stage2: compiler/stage2/build/Hoopl/Block.o In-Reply-To: <043.cd9c2f13d20866525a2d25a84f929b95@haskell.org> References: <043.cd9c2f13d20866525a2d25a84f929b95@haskell.org> Message-ID: <058.36e5c3986a1098ec1bae413b590c7a4f@haskell.org> #14541: Stg lint failure while building ghc-stage2: compiler/stage2/build/Hoopl/Block.o -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Changes (by duog): * Attachment "ticket-dump-14541.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 21:02:50 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 21:02:50 -0000 Subject: [GHC] #14536: Ghc panics while building stage2 with -dstg-lint In-Reply-To: <043.07052cd8274441bc63c2d750cdfb2370@haskell.org> References: <043.07052cd8274441bc63c2d750cdfb2370@haskell.org> Message-ID: <058.2b684d59df08737fb23782fcf5e52c44@haskell.org> #14536: Ghc panics while building stage2 with -dstg-lint -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: stg-lint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4242 Wiki Page: | -------------------------------------+------------------------------------- Changes (by duog): * status: new => patch * differential: => Phab:D4242 Comment: Fixed this one, found another: ticket:14541 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 21:06:30 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 21:06:30 -0000 Subject: [GHC] #14528: LLVM's CallAnalyzer Breaks In-Reply-To: <044.27305b362437d331be59330d3192840e@haskell.org> References: <044.27305b362437d331be59330d3192840e@haskell.org> Message-ID: <059.84639484ca970bcabe2bde44f1f86acc@haskell.org> #14528: LLVM's CallAnalyzer Breaks -------------------------------------+------------------------------------- Reporter: kavon | Owner: kavon Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.2.1 Resolution: | Keywords: inline Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: 11295 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kavon): * Attachment "even_simpler.ll" added. significantly reduced program that exhibits the same crashing behavior while determining InlineCost. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 21:13:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 21:13:46 -0000 Subject: [GHC] #14541: Stg lint failure while building ghc-stage2: compiler/stage2/build/Hoopl/Block.o In-Reply-To: <043.cd9c2f13d20866525a2d25a84f929b95@haskell.org> References: <043.cd9c2f13d20866525a2d25a84f929b95@haskell.org> Message-ID: <058.7122aa647d42518017d86c4e7a60993c@haskell.org> #14541: Stg lint failure while building ghc-stage2: compiler/stage2/build/Hoopl/Block.o -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 duog): It seems that `dataConRepArity` is returning 2 for Just0. Shouldn't one of those be being discarded as an "existential dictionary"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 21:19:49 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 21:19:49 -0000 Subject: [GHC] #14541: Stg lint failure while building ghc-stage2: compiler/stage2/build/Hoopl/Block.o In-Reply-To: <043.cd9c2f13d20866525a2d25a84f929b95@haskell.org> References: <043.cd9c2f13d20866525a2d25a84f929b95@haskell.org> Message-ID: <058.6fea2d2e4cd25e78c3fd68c9661086a0@haskell.org> #14541: Stg lint failure while building ghc-stage2: compiler/stage2/build/Hoopl/Block.o -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: stg-lint 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 duog): * keywords: => stg-lint -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 28 22:21:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Nov 2017 22:21:10 -0000 Subject: [GHC] #14542: Renamer / typechecker hang (UndecidableSuperClasses) Message-ID: <051.853153405275572272973f4f54ae92da@haskell.org> #14542: Renamer / typechecker hang (UndecidableSuperClasses) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple UndecidableSuperClasses | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Adapted from [https://gist.github.com/ekmett/b26363fc0f38777a637d hask], this does not look like a normal superclass loop. Loop is avoided by removing `instance (Category p, Category q) => Category (Nat p q)`. {{{#!hs {-# language KindSignatures #-} {-# language PolyKinds #-} {-# language DataKinds #-} {-# language TypeFamilies #-} {-# language RankNTypes #-} {-# language NoImplicitPrelude #-} {-# language FlexibleContexts #-} {-# language MultiParamTypeClasses #-} {-# language GADTs #-} {-# language ConstraintKinds #-} {-# language FlexibleInstances #-} {-# language TypeOperators #-} {-# language ScopedTypeVariables #-} {-# language DefaultSignatures #-} {-# language FunctionalDependencies #-} {-# language UndecidableSuperClasses #-} {-# language UndecidableInstances #-} {-# language TypeInType #-} import GHC.Types (Constraint, Type) type Cat i = i -> i -> Type newtype Y p a b = Y { getY :: p b a } class (Functor p, Dom p ~ Op p, Cod p ~ Nat p (->), Ob (Op p) ~ Ob p) => Category (p :: Cat i) where type Op p :: Cat i type Op p = Y p type Ob p :: i -> Constraint class (Category (Dom f), Category (Cod f)) => Functor (f :: i -> j) where type Dom f :: Cat i type Cod f :: Cat j data Nat :: Cat i -> Cat j -> Cat (i -> j) instance (Category p, Category q) => Category (Nat p q) }}} I get {{{ $ ghci2 -ignore-dot-ghci -v /tmp/Hangs.hs GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 8.3.20171122, stage 2 booted by GHC version 8.2.1 ... Loading package integer-gmp-1.0.1.0 ... linking ... done. Loading package base-4.11.0.0 ... linking ... done. *** Parser [source]: !!! Parser [source]: finished in 0.66 milliseconds, allocated 0.136 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.43 milliseconds, allocated 0.233 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.23 milliseconds, allocated 0.167 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.35 milliseconds, allocated 0.284 megabytes *** Parser [source]: !!! Parser [source]: finished in 0.21 milliseconds, allocated 0.197 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.52 milliseconds, allocated 0.268 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.23 milliseconds, allocated 0.113 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.46 milliseconds, allocated 0.334 megabytes *** Chasing dependencies: Chasing modules from: !!! Chasing dependencies: finished in 0.14 milliseconds, allocated 0.047 megabytes Stable obj: [] Stable BCO: [] unload: retaining objs [] unload: retaining bcos [] Ready for upsweep [] Upsweep completely successful. *** Deleting temp files: Deleting: *** Chasing dependencies: Chasing modules from: */tmp/Hangs.hs !!! Chasing dependencies: finished in 6.10 milliseconds, allocated 10.504 megabytes Stable obj: [] Stable BCO: [] unload: retaining objs [] unload: retaining bcos [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2017-11-28 22:14:57.810561584 UTC ms_mod = Main, ms_textual_imps = [(Nothing, GHC.Types)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file /tmp/Hangs.hs *** Checking old interface for Main (use -ddump-hi-diffs for more details): [1 of 1] Compiling Main ( /tmp/Hangs.hs, interpreted ) *** Parser [Main]: !!! Parser [Main]: finished in 2.63 milliseconds, allocated 4.821 megabytes *** Renamer/typechecker [Main]: }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 05:17:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 05:17:42 -0000 Subject: [GHC] #14543: Broken links all over the web Message-ID: <050.68369ac18f386c23d7f3ab3304bfe179@haskell.org> #14543: Broken links all over the web -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- Example: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide /type-families.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 05:18:16 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 05:18:16 -0000 Subject: [GHC] #14543: Broken links to docs all over the web (was: Broken links all over the web) In-Reply-To: <050.68369ac18f386c23d7f3ab3304bfe179@haskell.org> References: <050.68369ac18f386c23d7f3ab3304bfe179@haskell.org> Message-ID: <065.f5d64bcbfae0b49a67b63079ce8b3f04@haskell.org> #14543: Broken links to docs all over the web -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 05:19:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 05:19:10 -0000 Subject: [GHC] #14543: Broken links to docs all over the web In-Reply-To: <050.68369ac18f386c23d7f3ab3304bfe179@haskell.org> References: <050.68369ac18f386c23d7f3ab3304bfe179@haskell.org> Message-ID: <065.ca84ecc2ee4382dc33b1d4e4c4f5da8f@haskell.org> #14543: Broken links to docs all over the web -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 SimonHengel): This kind of links are used on stack overflow, in blog posts, other documentation, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 10:42:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 10:42:07 -0000 Subject: [GHC] #14503: Killing a thread will block if there is another process reading from a handle In-Reply-To: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> References: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> Message-ID: <062.0865270287734545eafa664ab30f8aa5@haskell.org> #14503: Killing a thread will block if there is another process reading from a handle -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dnadales): Thanks for checking this out. I've tried your example with GHC 8.2.1, and it also hangs when killing the reader. I'm also running a 64-bit version of Windows 10, so I don't know what might be happening. How did you launch the two processes? On a Unix like terminal emulator? (I've tried on MINGW64, but there it is even worse since I don't see any output). In my case I was using Windows Power Shell, but I get the same result in the old Windows Command Prompt. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 11:01:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 11:01:08 -0000 Subject: [GHC] #14503: Killing a thread will block if there is another process reading from a handle In-Reply-To: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> References: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> Message-ID: <062.0ca13404fc85383c29718b40f2d92628@haskell.org> #14503: Killing a thread will block if there is another process reading from a handle -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dnadales): I'm using stack as build tool. To discard the possibility of any noise introduced by it, I downloaded the 8.2.1 version of the Haskell platform and I still get the same results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 11:04:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 11:04:20 -0000 Subject: [GHC] #14503: Killing a thread will block if there is another process reading from a handle In-Reply-To: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> References: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> Message-ID: <062.82a0a18720e3dbe2a99cb0af68deaffa@haskell.org> #14503: Killing a thread will block if there is another process reading from a handle -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dnadales): And regarding the tests, isn't it possible to include the example you posted above as an integration test for the Control.Concurrent library? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 12:33:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 12:33:48 -0000 Subject: [GHC] #14503: Killing a thread will block if there is another process reading from a handle In-Reply-To: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> References: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> Message-ID: <062.421ceddf8136f27526d6ac797e31354d@haskell.org> #14503: Killing a thread will block if there is another process reading from a handle -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dnadales): Reading from sockets leads to the same behavior. However, closing the socket before killing the thread works: {{{#!hs import qualified Data.ByteString.Char8 as C import Network.Socket hiding (recv, recvFrom, send, sendTo) import Network.Socket.ByteString readWithinNSecsBinary :: IO () readWithinNSecsBinary = withSocketsDo $ do addrinfos <- getAddrInfo Nothing (Just "") (Just "9090") let serveraddr = head addrinfos sock <- socket (addrFamily serveraddr) Stream defaultProtocol connect sock (addrAddress serveraddr) readerTid <- forkIO $ sockReader sock threadDelay (3 * 10^6) putStrLn "Killing the binary reader" putStrLn "Closing the socket" close sock -- Wihout this line the client will block putStrLn "Socket closed!" killThread readerTid putStrLn "Binary reader thread killed" where sockReader sock = do putStrLn "Receiving ..." msg <- recv sock 1024 putStr "Received " C.putStrLn msg }}} This results in {{{#!text Receiving ... Killing the binary reader Closing the socket Socket closed! dangling-connections-exe.EXE: Network.Socket.recvBuf: failed (No error) Binary reader thread killed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 12:45:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 12:45:54 -0000 Subject: [GHC] #14541: Stg lint failure while building ghc-stage2: compiler/stage2/build/Hoopl/Block.o In-Reply-To: <043.cd9c2f13d20866525a2d25a84f929b95@haskell.org> References: <043.cd9c2f13d20866525a2d25a84f929b95@haskell.org> Message-ID: <058.6274e47cc92a675977214194b96a7379@haskell.org> #14541: Stg lint failure while building ghc-stage2: compiler/stage2/build/Hoopl/Block.o -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: stg-lint 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): This is another example of how, after the unarisation pass, we have discarded void argument. (A void argument is one of zero width.) The type of `JustO` is {{{ JustO :: forall ex t. (ex ~# O) => t -> MaybeO ex t }}} So it does take two value arguments, one of zero width. After unarisation these void arguments are gone; so the Lint check will have to account for that. I suppose there could be a flag passed in to STG-Lint to tell it whether or not those void args are there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 13:03:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 13:03:39 -0000 Subject: [GHC] #14542: Renamer / typechecker hang (UndecidableSuperClasses) In-Reply-To: <051.853153405275572272973f4f54ae92da@haskell.org> References: <051.853153405275572272973f4f54ae92da@haskell.org> Message-ID: <066.67bf3e2b7d334c5712ea043051c3a7a8@haskell.org> #14542: Renamer / typechecker hang (UndecidableSuperClasses) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | UndecidableSuperClasses 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): Well, every given `(Category p)` constraint will give rise to four superclasses {{{ class (Functor p, Dom p ~ Op p, Cod p ~ Nat p (->), Ob (Op p) ~ Ob p) => Category (p :: Cat i) where }}} That `Functor p` constraint will give rise to two `(Category (Dom p), Category (Cod p))` constraints. {{{ class (Category (Dom f), Category (Cod f)) => Functor (f :: i -> j) where }}} And so on. So in each round of superclass expansion we get double the number of constraints. Result: exponential blowup. So I'd say this is expected bahaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 13:12:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 13:12:41 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.8b59bdf80e14154a49daf92a3327be98@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johndoe): > The first off, the numbered versions are a component of the newer Visual Studio C++ Runtimes. Hence the versions. Each release is tied directly to a visual studio release. We do not have the rights to redistribute these files Well, I think you do. Not only vc-redist installers, but even separate files, if you need. According to https://msdn.microsoft.com/en-us/library/ms235299.aspx: It's also possible to directly install redistributable Visual C++ DLLs in the application local folder, which is the folder that contains your executable application file. > See ​https://msdn.microsoft.com/en-us/library/abx4dbyh.aspx You always need a C runtime. But MSVCRT.DLL is not C runtime: https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 So linking to it is against MS guidance. But ok, I am not going to make holy war from it. My problem is that in my system MSVCRT.DLL just does not contain required exports (but 'numbered' msvcr90.dll does) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 13:44:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 13:44:17 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.48acf709345946a78e78ac31d059d60b@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): > Well, I think you do. Not only vc-redist installers, but even separate files, if you need. According to ​https://msdn.microsoft.com/en- us/library/ms235299.aspx: Yes and how would this work? You could call `ghc foo.hs` and the resulting `foo.exe` would not run because the required DLLs are not on your path. Doing this is a major deployment issue. And you're confusing two things. These are the distributable files. There's not enough for the compiler. For the compiler you'd need the appropriate import libraries as well which I don't think are in those packages (I haven't checked.). The licensing issue comes from the fact that we don't just use them to run, we also need to be able to link against them. So we need to redistribute some form of static code. > But MSVCRT.DLL is not C runtime: ​https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 So linking to it is against MS guidance. The link explicitly says it's not the Visual C/C++ runtime. It is most definitely however a C runtime. Also I don't consider a blog post about it official policy. If Raymond Chen doesn't want people to link against it, he should provide a reasonable alternative. > But ok, I am not going to make holy war from it. My problem is that in my system MSVCRT.DLL just does not contain required exports (but 'numbered' msvcr90.dll does) Then this is a bug in your application. GHC by default does not produce binaries that use symbols not provided by the dll. The mingw-w64 project goes to great lengths to make sure the import libraries for msvcrt do not contain symbols not available in as far back as XP. So either you hit a bug in their import library (which is certainly possible and has happened and should report it there with a repro) or the application is doing something weird. If you think it's us that are linking against a symbol that shouldn't be available by default, then that's a separate issue that I'm perfectly willing to address. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 14:05:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 14:05:19 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.03220bbc396768123c7bdedfa9908f1a@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Also just to clarify, I'm not trying to be difficult, even though it may come across that way. However not linking against `msvcrt.dll` imposes serious constraints and comes with quite a few caveats. So this isn't as simple as you might think, this would require not only GHC changes but also changing GCC's default behaviour. That said, if you have an application that does not explicitly request to use this symbol you say is missing I'd be happy to take a look at this given a repro. Also do note that there was a mixup with some crt symbols in the mingw-w64 GCC 6.2 that we bundle. This should have however resulted in linker errors and not incorrect linking. You could try GHC 8.0 to see if it's a result of that issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 14:54:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 14:54:37 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.359ed3b895db64677bfe435195fec83c@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johndoe): >That said, if you have an application that does not explicitly request to use this symbol you say is missing I'd be happy to take a look at this given a repro. My application is Pandoc 2 (https://github.com/jgm/pandoc/) In imports table it has msvcrt.dll\_wsplitpath_s. msvcrt.dll in windows XP does not have this function (but has plain "_wsplitpath"). Pandoc built with old version of GHC does hot have this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 15:15:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 15:15:17 -0000 Subject: [GHC] #14478: Abstract pattern synonyms (for hsig and hs-boot) In-Reply-To: <045.8d2821cb171cb8f59be6aa602942a2eb@haskell.org> References: <045.8d2821cb171cb8f59be6aa602942a2eb@haskell.org> Message-ID: <060.efd5b4021e67fd9dd3fa1e4fe0b8e786@haskell.org> #14478: Abstract pattern synonyms (for hsig and hs-boot) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | 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 simonpj): We also need to know arity because, type system aside, we still need to know how many arguments the pattern synonym should be applied to in a pattern. Eg {{{ f (P x) vs f (P x y) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 15:15:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 15:15:23 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.dcfa2170e508b1491dd31371041e229d@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): GHC does not support Windows XP anymore, so I think Pandoc is allowed to do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 16:50:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 16:50:41 -0000 Subject: [GHC] #14541: Stg lint failure while building ghc-stage2: compiler/stage2/build/Hoopl/Block.o In-Reply-To: <043.cd9c2f13d20866525a2d25a84f929b95@haskell.org> References: <043.cd9c2f13d20866525a2d25a84f929b95@haskell.org> Message-ID: <058.f84ca2905a8b248fa6d2afb5858a12a1@haskell.org> #14541: Stg lint failure while building ghc-stage2: compiler/stage2/build/Hoopl/Block.o -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: stg-lint 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 duog): * owner: (none) => duog Comment: In retrospect that's quite unsurprising. I'll see about folding a fix into Phab:D4242 since this is really the same problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 16:59:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 16:59:53 -0000 Subject: [GHC] #14503: Killing a thread will block if there is another process reading from a handle In-Reply-To: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> References: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> Message-ID: <062.7a0874533bfc5dba58f8bc587bdac324@haskell.org> #14503: Killing a thread will block if there is another process reading from a handle -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => Comment: Reopening as the reporter still sees this in 8.2.1. > How did you launch the two processes? On a Unix like terminal emulator? (I've tried on MINGW64, but there it is even worse since I don't see any output). In my case I was using Windows Power Shell, but I get the same result in the old Windows Command Prompt. Yes, in a mingw64 msys2 environment under `bash`. > And regarding the tests, isn't it possible to include the example you posted above as an integration test for the `Control.Concurrent` library? We could propose that it be added to `async`, but that won't help catch if GHC regresses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 17:05:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 17:05:31 -0000 Subject: [GHC] #14544: doCorePass has at least one missing case Message-ID: <049.4d90cc3cc6b5380801189db1b57310d5@haskell.org> #14544: doCorePass has at least one missing case -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- There is a catch all at the end of `doCorePass` which hides the fact that `doCorePass` should be total. In particular `doCorePass` is not implemented for `CoreOccurAnal` and so either `CoreOccurAnal` should be removed from `CoreToDo` or implemented properly in `doCorePass`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 17:05:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 17:05:53 -0000 Subject: [GHC] #14511: indexArray# getting poorly deferred In-Reply-To: <046.562c7ba6b9fb319f3069f981d147d69c@haskell.org> References: <046.562c7ba6b9fb319f3069f981d147d69c@haskell.org> Message-ID: <061.0dbcab82240a8071d64ef4e95a0b78a6@haskell.org> #14511: indexArray# getting poorly deferred -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b6428af8760737975f9b2959f9536c0404d636ec/ghc" b6428af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b6428af8760737975f9b2959f9536c0404d636ec" Comments only: Trac #14511 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 17:37:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 17:37:53 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.045c7f208e63ecaa5b286e41ab54cbf8@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Did this patch ever get submitted? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 17:54:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 17:54:53 -0000 Subject: [GHC] #14543: Broken links to docs all over the web In-Reply-To: <050.68369ac18f386c23d7f3ab3304bfe179@haskell.org> References: <050.68369ac18f386c23d7f3ab3304bfe179@haskell.org> Message-ID: <065.d05aae75b1fae76b09f5f2532a106b18@haskell.org> #14543: Broken links to docs all over the web -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 bgamari): * status: new => closed * resolution: => wontfix Comment: I really don't know what we can do about this; the `/latest` directory is by definition the most recent release. There is relatively little we can do if people post unstable links. The correct thing to do here is to take care that long-lived text only contain stable links (e.g. for a particular GHC version). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 20:06:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 20:06:44 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.caaa537ef996369dcd478ea8061758da@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Comment (by alexbiehl): I have hit a problem. Using ticket #7258 as a base line I figured that most of the closures we generate during `Read`/`Show` deriving are updatable thunks: {{{ let [fv1 fv2 ... fvn] outer = \u [] -- 'u' for updatable let [fv1 fv2 ... fvn] inner = \u [] ... }}} Applying the NestedClosure idea gets us: {{{ let [fv1 fv2 ... fvn] outer = \u [] let [outer{fv1 fv2 ... fvn}] inner = \u [] ... }}} Now, when forcing `outer` we push an update frame which overwrites `outer`s closure to be an indirection to the resulting value hereby turning the free variables effectively into garbage. We now have no safe way to access `outer`s free variables from `inner`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 20:29:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 20:29:30 -0000 Subject: [GHC] #14528: LLVM's CallAnalyzer Breaks In-Reply-To: <044.27305b362437d331be59330d3192840e@haskell.org> References: <044.27305b362437d331be59330d3192840e@haskell.org> Message-ID: <059.3d33d255b07f42c1186561c746d5097e@haskell.org> #14528: LLVM's CallAnalyzer Breaks -------------------------------------+------------------------------------- Reporter: kavon | Owner: kavon Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.2.1 Resolution: | Keywords: inline Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: 11295 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kavon): Reported here: https://bugs.llvm.org/show_bug.cgi?id=35469 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 21:01:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 21:01:19 -0000 Subject: [GHC] #14503: Killing a thread will block if there is another process reading from a handle In-Reply-To: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> References: <047.24f5cc40097f8ccae7b19a3d03f5dd37@haskell.org> Message-ID: <062.c17fa7de39f230eefe07adc4f4905aba@haskell.org> #14503: Killing a thread will block if there is another process reading from a handle -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dnadales): Sorry that I don't quote your message but I'm replying from the phone. Could you see if the bug is reproducible from a windows command prompt? And for adding tests I guess it should not be added to async since it is not related to it (I would say). I don't know if I can help somehow. I'll be happy to write a small test, but if we cannot use sockets in the test then there's nothing I can do (besides setting up appveyor in a personal repository and check for this kind of regressions periodically). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 22:51:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 22:51:23 -0000 Subject: [GHC] #11503: TypeError woes (incl. pattern match checker) In-Reply-To: <047.92c703997fce99f046395b5c889b1ab4@haskell.org> References: <047.92c703997fce99f046395b5c889b1ab4@haskell.org> Message-ID: <062.3977aaf27d4b1b2be288d7790798574a@haskell.org> #11503: TypeError woes (incl. pattern match checker) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternMatchWarnings, | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14141 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I ran into this issue a few days ago, and it really is annoying. We're forced to choose between a constraint the pattern checker will work with properly (`'True ~ 'False`) and a constraint that will give a good error message when accidentally matching against `MkT2` (`TypeError ...`). There's a sort of workaround, but it's really horrible: instead of `'True ~ 'False`, use something like `"" ~ "This is an error message!"`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 22:52:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 22:52:08 -0000 Subject: [GHC] #11503: TypeError woes (incl. pattern match checker) In-Reply-To: <047.92c703997fce99f046395b5c889b1ab4@haskell.org> References: <047.92c703997fce99f046395b5c889b1ab4@haskell.org> Message-ID: <062.b5bd27d0c62687b9f27e8568d2af407f@haskell.org> #11503: TypeError woes (incl. pattern match checker) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternMatchWarnings, | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #14141 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) * failure: None/Unknown => Incorrect error/warning at compile-time * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 23:45:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 23:45:56 -0000 Subject: [GHC] #14545: -prof causes -N to default to 1 Message-ID: <046.7d4ffefef4202d01a6900c8ce3a34ece@haskell.org> #14545: -prof causes -N to default to 1 -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given a simple test program which prints `getNumCapabilities`: {{{#!hs import Control.Concurrent main :: IO () main = print =<< getNumCapabilities }}} Compiling this with `-threaded` and running the program with `+RTS -N` is supposed to set the number of capabilities to the number of cores on the machine. This normally prints 8 on my machine: {{{#!bash $ rm -rf Main Main.hi Main.o && ghc -threaded Main.hs && ./Main +RTS -N [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... 8 }}} But when I compile with `-prof`, it prints 1 instead! Expected output: still 8. {{{#!bash $ rm -rf Main Main.hi Main.o && ghc -prof -threaded Main.hs && ./Main +RTS -N [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... 1 }}} If I use `+RTS -N8` instead, it prints 8 as expected. Reproduced with GHC 8.0.2 and GHC 8.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 29 23:52:54 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Nov 2017 23:52:54 -0000 Subject: [GHC] #14545: -prof causes -N to default to 1 In-Reply-To: <046.7d4ffefef4202d01a6900c8ce3a34ece@haskell.org> References: <046.7d4ffefef4202d01a6900c8ce3a34ece@haskell.org> Message-ID: <061.19d6e7b581b6c29f6b276bb5366bc295@haskell.org> #14545: -prof causes -N to default to 1 -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by gelisam: Old description: > Given a simple test program which prints `getNumCapabilities`: > > {{{#!hs > import Control.Concurrent > > main :: IO () > main = print =<< getNumCapabilities > }}} > > Compiling this with `-threaded` and running the program with `+RTS -N` is > supposed to set the number of capabilities to the number of cores on the > machine. This normally prints 8 on my machine: > > {{{#!bash > $ rm -rf Main Main.hi Main.o && ghc -threaded Main.hs && ./Main +RTS -N > [1 of 1] Compiling Main ( Main.hs, Main.o ) > Linking Main ... > 8 > }}} > > But when I compile with `-prof`, it prints 1 instead! Expected output: > still 8. > > {{{#!bash > $ rm -rf Main Main.hi Main.o && ghc -prof -threaded Main.hs && ./Main > +RTS -N > [1 of 1] Compiling Main ( Main.hs, Main.o ) > Linking Main ... > 1 > }}} > > If I use `+RTS -N8` instead, it prints 8 as expected. > > Reproduced with GHC 8.0.2 and GHC 8.8.2. New description: Given a simple test program which prints `getNumCapabilities`: {{{#!hs import Control.Concurrent main :: IO () main = print =<< getNumCapabilities }}} Compiling this with `-threaded` and running the program with `+RTS -N` is supposed to set the number of capabilities to the number of cores on the machine. This normally prints 8 on my machine: {{{#!bash $ rm -rf Main Main.hi Main.o && ghc -threaded Main.hs && ./Main +RTS -N [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... 8 }}} But when I compile with `-prof`, it prints 1 instead! Expected output: still 8. {{{#!bash $ rm -rf Main Main.hi Main.o && ghc -prof -threaded Main.hs && ./Main +RTS -N [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... 1 }}} If I use `+RTS -N8` instead, it prints 8 as expected. Reproduced with GHC 8.0.2 and GHC 8.2.2. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 00:28:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 00:28:51 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.ef36532f64beeea7cf7b423935667db9@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I rebased the branch here - https://github.com/mpickering/ghc/tree/nested- cpr I get 7 test failures running in simpleCore. There is also a core lint error when running a fresh build. I put it up on phab as well for easier viewing. (https://phabricator.haskell.org/D4244) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 03:02:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 03:02:23 -0000 Subject: [GHC] #14543: Broken links to docs all over the web In-Reply-To: <050.68369ac18f386c23d7f3ab3304bfe179@haskell.org> References: <050.68369ac18f386c23d7f3ab3304bfe179@haskell.org> Message-ID: <065.77aa4809d68a9eb6ff67e26f156b3513@haskell.org> #14543: Broken links to docs all over the web -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by SimonHengel): Well, that didn't happen in the past. It's easy to blame the content authors who linked to the users guide in the past. But that won't improve anything. Just one more example is here: https://prime.haskell.org/wiki/LiberalTypeSynonyms The authors of this page are Simon Peyton Jones and Simon Marlow, both also authors of the users guide. They didn't get it right, and so many others didn't. Literally every link to the users guide is broken right now. Closing this as "wontfix" is like pretending that there isn't any problem. As I see it, as a content creator it is your responsibility to keep URLs stable. If you don't do it it hurts your users, reduces your visibility and has a negative impact on your Google ranking. So what can we do to mitigate this situation? Here is a non-comprehensive list of two options: - Scan the server logs for 404, sort them by frequency and create redirects based on that. - Turn requests to {{{/latest}}} into redirects to the canonical URL so that this situation won't happen in the future (assuming that most of the time URLs are actually copied and pasted) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 04:21:37 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 04:21:37 -0000 Subject: [GHC] #14545: -prof causes -N to default to 1 In-Reply-To: <046.7d4ffefef4202d01a6900c8ce3a34ece@haskell.org> References: <046.7d4ffefef4202d01a6900c8ce3a34ece@haskell.org> Message-ID: <061.16d3ff521753d365894838f4038d3e3e@haskell.org> #14545: -prof causes -N to default to 1 -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4245 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4245 * milestone: => 8.4.1 Comment: Here's a probable fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 04:24:58 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 04:24:58 -0000 Subject: [GHC] #14543: Broken links to docs all over the web In-Reply-To: <050.68369ac18f386c23d7f3ab3304bfe179@haskell.org> References: <050.68369ac18f386c23d7f3ab3304bfe179@haskell.org> Message-ID: <065.505eb9f7b98fa2d893cc37d73edaf02d@haskell.org> #14543: Broken links to docs all over the web -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.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 bgamari): * status: closed => new * component: Compiler => Documentation * resolution: wontfix => Comment: Thanks for the concrete steps. This helps immensely. > Turn requests to `/latest` into redirects to the canonical URL so that this situation won't happen in the future (assuming that most of the time URLs are actually copied and pasted) Yes, this sounds plausible. I will look into what it will take to make this happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 04:25:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 04:25:05 -0000 Subject: [GHC] #14543: Broken links to docs all over the web In-Reply-To: <050.68369ac18f386c23d7f3ab3304bfe179@haskell.org> References: <050.68369ac18f386c23d7f3ab3304bfe179@haskell.org> Message-ID: <065.9957c951cb3c474daeda398a1122367d@haskell.org> #14543: Broken links to docs all over the web -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.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 bgamari): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 08:22:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 08:22:09 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.66de57414219a6b972a8faae418d3fb3@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Comment (by alexbiehl): Ok, compiling with optimizations somewhat reduces the amount of updatable thunks. Possibly because of demand analysis. We must be careful to not share updatable thunks. I have to measure the impact but I suspect this will greatly reduce the effect of this transformation and we should think about a different scheme. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 09:20:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 09:20:16 -0000 Subject: [GHC] #14546: -Woverlapping-patterns warns on wrong patterns for Int Message-ID: <046.65cf2f969bf40f1f8653cdbe0242cf31@haskell.org> #14546: -Woverlapping-patterns warns on wrong patterns for Int -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC-8.0 introduced a new warning on redundant pattern matches in `case` clauses. But there is something strange. {{{ $ cat RedundantCase.hs main :: IO () main = do case 0::Int of 0 -> putStrLn "A" 1 -> putStrLn "B" _ -> putStrLn "C" case 0::Int of 0 -> putStrLn "A" 1 -> putStrLn "B" 2 -> putStrLn "C" case 0::Integer of 0 -> putStrLn "A" 1 -> putStrLn "B" _ -> putStrLn "C" case 0::Integer of 0 -> putStrLn "A" 1 -> putStrLn "B" 2 -> putStrLn "C" case 0::Integer of 1 -> putStrLn "B" 2 -> putStrLn "C" let dummy :: Integer dummy = 0 case dummy of 0 -> putStrLn "A" 1 -> putStrLn "B" _ -> putStrLn "C" case "foo" of "foo" -> putStrLn "A" "bar" -> putStrLn "B" "baz" -> putStrLn "C" if True then putStrLn "X" else putStrLn "Y" }}} {{{ $ ghc-8.2.2 -Wall RedundantCase.hs [1 of 1] Compiling Main ( RedundantCase.hs, RedundantCase.o ) RedundantCase.hs:4:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 0 -> ... | 4 | 0 -> putStrLn "A" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:5:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 1 -> ... | 5 | 1 -> putStrLn "B" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:8:4: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: 0 | 8 | case 0::Int of | ^^^^^^^^^^^^^^... RedundantCase.hs:9:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 0 -> ... | 9 | 0 -> putStrLn "A" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:10:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 1 -> ... | 10 | 1 -> putStrLn "B" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:11:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 2 -> ... | 11 | 2 -> putStrLn "C" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:15:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 1 -> ... | 15 | 1 -> putStrLn "B" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:16:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: _ -> ... | 16 | _ -> putStrLn "C" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:20:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 1 -> ... | 20 | 1 -> putStrLn "B" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:21:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 2 -> ... | 21 | 2 -> putStrLn "C" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:23:4: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: 0 | 23 | case 0::Integer of | ^^^^^^^^^^^^^^^^^^... RedundantCase.hs:24:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 1 -> ... | 24 | 1 -> putStrLn "B" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:25:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 2 -> ... | 25 | 2 -> putStrLn "C" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:34:4: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: [] (p:_) where p is not one of {'b', 'f'} ['b'] ('b':p:_) where p is not one of {'a'} ... | 34 | case "foo" of | ^^^^^^^^^^^^^... Linking RedundantCase ... }}} In the first case it warns about the wrong patterns, in the second case it warns about all patterns and a non-exhaustive pattern list. In the following three cases using `Integer` the warnings seem to be correct. The next case shows that I can suppress the warning if I hide the constant nature of the case selector a bit. Then a case on a `String` - GHC does not seem to try to detect redundant pattern matches but falls back to a general test on exhaustive pattern lists. Finally, in a constant `case` on `Bool` I can avoid the warning using a plain `if-then-else`. Now I wonder what the purpose of the warning is at all. First I thought that it wants to warn me, that the patterns overlap, i.e. pattern `_` contains the already handled case `0`. This does not seem to be the purpose of the warning - and such overlapping patterns are pretty common, aren't they? Second thought: GHC wants to warn me about redundant patterns in the presence of a constant case selector. But then, it does so with varying degrees of success: For `Integer` it works, but not for `Int` or `String`. Is it really only about constant case selectors? Then, not only some pattern matches are redundant but the whole `case` clause is redundant. Then again, can't we assume that the programmer wrote such a `case` clause by intend? At least, this is how I use a `case` clause with constant selector: as a type-safe way to out-comment alternative implementations. Thus my question: Where is this warning useful? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 10:01:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 10:01:52 -0000 Subject: [GHC] #14546: -Woverlapping-patterns warns on wrong patterns for Int In-Reply-To: <046.65cf2f969bf40f1f8653cdbe0242cf31@haskell.org> References: <046.65cf2f969bf40f1f8653cdbe0242cf31@haskell.org> Message-ID: <061.519881801e0280669e39b91147be8b30@haskell.org> #14546: -Woverlapping-patterns warns on wrong patterns for Int -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: Resolution: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings Comment: Thanks. There are quite a few [wiki:PatternMatchCheck tickets related to the pattern-match warning checker]. It'd be great if someone wanted to take leadership on that front. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 15:44:08 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 15:44:08 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.45980513d2ed5cb383750d3382203a99@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To be clear here: I'm not proposing to change anything regarding the rules for ordinary functions (I'll save that for #14288, which will require a GHC proposal). I'm only proposing to change the rules for pattern synonyms, since (1) pattern synonyms are a more experimental feature, and (2) the current rules governing them are clearly broken, as this ticket demonstrates. Replying to [comment:8 simonpj]: > 1. Where are the implicitly-added foralls? Example > {{{ > pattern SS :: > forall (t :: k'). > () > => forall (a :: kk -> k') (n :: kk). > (t ~ a n) > => blah > }}} > This is short for > {{{ > pattern SS :: > forall {k'}. forall (t :: k'). > () > => forall {kk}. forall (a :: kk -> k') (n :: kk). > (t ~ a n) > => blah > }}} Ideally, this would be the case. The typechecker thinks this way, but unfortunately, the renamer does not. It thinks it's this: {{{#!hs pattern SS :: forall {k' kk}. forall (t :: k'). () => forall (a :: kk -> k') (n :: kk). (t ~ a n) => blah }}} That is, the renamer believes everything implicitly quantified is put up front, as as a result, tries to bring `kk` into scope over the body of `SS`, leading to the internal error seen above. I propose to simply not bring `kk` into scope in the renamer. That's all. (I tried implementing this last week, but this turns out to be quite tricky, so I gave up.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 20:29:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 20:29:40 -0000 Subject: [GHC] #14531: tcIfaceGlobal (local): not found In-Reply-To: <044.574a009d0a229a581813260133be5712@haskell.org> References: <044.574a009d0a229a581813260133be5712@haskell.org> Message-ID: <059.4d4f97ecb5f70faa8e9dce81363bd065@haskell.org> #14531: tcIfaceGlobal (local): not found -------------------------------------+------------------------------------- Reporter: bigos | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Phyx-): * keywords: Windows Msys2 => * os: Windows => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple Comment: Thanks for the report, this isn't Windows specific so I'm throwing it in the general pool. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 21:02:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 21:02:50 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.40b69f257ded40e1d982a32bab1dc93a@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): Given the following module {{{#!hs {-# LANGUAGE TypeFamilies, GADTs, FlexibleInstances, StandaloneDeriving, DeriveDataTypeable #-} {-# LANGUAGE DataKinds #-} module Oddity where import Data.Data data GhcPass (p :: Pass) data Pass = Parsed | Renamed | Typechecked deriving (Data) deriving instance Typeable p => Data (GhcPass p) type family XOverLit x type instance XOverLit (GhcPass 'Parsed) = Int type instance XOverLit (GhcPass 'Renamed) = Int type instance XOverLit (GhcPass 'Typechecked) = Char data Foo p = Foo (XOverLit p) deriving instance (Typeable p) => Data (Foo (GhcPass p)) }}} I do not understand why deriving the `Data` instance for `Foo (GhcPass p)` fails {{{ Oddity.hs:21:1-56: error: • Could not deduce (Data (XOverLit (GhcPass p))) arising from a use of ‘k’ }}} Is this a weakness in the deriving process? Because as I understand it, there is a concrete value for every `(GhcPass p)`, given the way `GhcPass` is defined as being indexed by `Pass`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 21:13:59 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 21:13:59 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.cedd767fc35b26799f738908c4f525e0@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Sorry for the delay, haven't had much time to spend on GHC. As you know we depend on GCC which gets it's crt definitions from the mingw-w64 project. As far as I am aware of, they were supposed to support XP until v5 of the crt release https://sourceforge.net/p/mingw-w64/mailman/message/35465862/ but this function was added in 2010: {{{ commit f532681f435090c3a0812bf02969821b211d5ca1 Author: Jonathan Yong <10walls at gmail.com> Date: Mon Aug 2 06:59:06 2010 +0000 2010-07-26 Jonathan Yong * lib32/msvcrt.def: Added secure and locale type symbols from Win7. * lib64/msvcrt.def: Likewise. git-svn-id: svn+ssh://svn.code.sf.net/p/mingw-w64/code/trunk at 3079 4407c894-4637-0410-b4f5-ada5f102cad1 }}} Which is why it's using it. But while that means I could in theory have a workaround for XP for this, it won't do you much good. Starting with 8.6 we're going to use system APIs only available in Windows Vista SP1 and higher (which is our minimum supported version, but we'll likely be moving this to Windows 7 too). As @refold said we don't support XP anymore, and I don't think it's feasible for us to, it requires too many workarounds in the runtime, and in some cases just not having a feature. So while I could solve this particular issue, I'm sure it still won't be useable. Sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 21:19:35 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 21:19:35 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.d920350890e4b398a5e7a1aedfa29e3d@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johndoe): Thank you -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 21:20:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 21:20:40 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.db074b6ba380c759bea5127555e4661c@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): My current thoughts 1. Plan F is complex, and requires special case treatment of traversals into extension points that are actually used. In the parts of TTG introduced so far, we are already making fairly substantial use of pass- specific data types in a seamless way. 2. Plan B is simple and works, and does not change the GHC API for any existing client users of traversals over the AST. We are already looking at an earliest land of the feature in GHC 8.6 (second half of 2018?) so the required GHC 8.2 bootstrap compiler is not an issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 22:10:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 22:10:14 -0000 Subject: [GHC] #14478: Abstract pattern synonyms (for hsig and hs-boot) In-Reply-To: <045.8d2821cb171cb8f59be6aa602942a2eb@haskell.org> References: <045.8d2821cb171cb8f59be6aa602942a2eb@haskell.org> Message-ID: <060.41459d5795e77d809a03d505de761ea7@haskell.org> #14478: Abstract pattern synonyms (for hsig and hs-boot) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | 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 goldfire): I actually like the proposed syntax with the ellipsis. I would just vote for `..` (two dots), because that's already a lexeme (and is what closed type families use). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 22:46:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 22:46:29 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.7f93c37644dcf908224cf8dd9bdf9ab8@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:41 alanz]: > Is this a weakness in the deriving process? Because as I understand it, there is a concrete value for every `(GhcPass p)`, given the way `GhcPass` is defined as being indexed by `Pass`. This is not how type families work. Type families only reduce when you provide arguments that match an instance in scope. `XOverlit (GhcPass p)` does not match any instances, and thus it doesn't reduce. If you want this to compile, you'll need something like this: {{{#!hs {-# LANGUAGE TypeFamilies, GADTs, FlexibleInstances, StandaloneDeriving, DeriveDataTypeable #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableInstances #-} module Oddity where import Data.Data data GhcPass (p :: Pass) data Pass = Parsed | Renamed | Typechecked deriving (Data) deriving instance Typeable p => Data (GhcPass p) type family XOverLit x type instance XOverLit (GhcPass 'Parsed) = Int type instance XOverLit (GhcPass 'Renamed) = Int type instance XOverLit (GhcPass 'Typechecked) = Char data Foo p = Foo (XOverLit p) deriving instance (Typeable p, Data (XOverLit (GhcPass p))) => Data (Foo (GhcPass p)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 22:48:20 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 22:48:20 -0000 Subject: [GHC] #14531: tcIfaceGlobal (local): not found In-Reply-To: <044.574a009d0a229a581813260133be5712@haskell.org> References: <044.574a009d0a229a581813260133be5712@haskell.org> Message-ID: <059.5838257676ef4f6abededaa55b4b8c2e@haskell.org> #14531: tcIfaceGlobal (local): not found -------------------------------------+------------------------------------- Reporter: bigos | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14382 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14382 Comment: Thanks for the bug report. This is a duplicate of #14382, so I'll close this ticket in favor of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 30 23:33:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Nov 2017 23:33:43 -0000 Subject: [GHC] #14539: untouchable type inside the constraints In-Reply-To: <046.e791a4fd7c5c8d50126f67c9980c3ee6@haskell.org> References: <046.e791a4fd7c5c8d50126f67c9980c3ee6@haskell.org> Message-ID: <061.4d3bbae5298fc8e1e40c87ef6585d349@haskell.org> #14539: untouchable type inside the constraints -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.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 goldfire): This is correct behavior by GHC. Untouchable variables are explained accessibly in the [https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/jfp- outsidein.pdf OutsideIn paper], sections 5.1 and 5.2. (I think you'll be able to get most of the meaning without reading prior sections.) Essentially, any type that GHC has to guess cannot be affected from code where an equality assumption is in effect. Your `sign :: Sign Double` happens in a context where the `FullShape sh ~ sh` equality can be assumed. It cannot thus affect the type that GHC guesses for `sign`, which is introduced outside the scope of that equality constraint. The solution is simply to annotate the type of `sign` when it is introduced: `... \(sign :: Sign Double) -> ...`, and you should be OK. If you agree with this analysis, please close the ticket. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler