- ghc-tickets - Haskell.org

[GHC] #15768: Using oneshot kqueue() on macOS
by GHC 13 Dec '18

13 Dec '18

#15768: Using oneshot kqueue() on macOS -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.6.1 Libraries | Keywords: KQueue, | Operating System: MacOS X oneshot, parallel build | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Oneshot kqueue() is disabled on macOS due to https://ghc.haskell.org/trac/ghc/ticket/7651 Recall that the paper "Mio: A High-Performance Multicore IO Manager for GHC" says: "Mio also uses kqueue on OS X, since Darwin, the foundation for Apple’s OS X, is a variant of BSD. However, we encountered problems running parallel builds of the GHC compiler using Mio as described above. We have been unable to uncover the underlying source of the problem to our satisfaction. However, several Internet discussions suggest that the implementation of kqueue and pipe on OS X are unstable. We were able to resolve the observed prob- lems on OS X by avoiding the use of one-shot mode on OS X, instead unregistering events after they are delivered, and by send- ing wakeup writes to a pipe monitored by the dispatcher threads’ kqueue instances on every event registration. With these changes, the behavior on OS X, including parallel builds of GHC, has been stable." Now the serious bug on KQueue has been fixed: - https://ghc.haskell.org/trac/ghc/ticket/13903 - https://phabricator.haskell.org/D3692 So, I guess it's time to use oneshot on macOS. A patch is attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15768> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15843: Tuple sections can't be quoted
by GHC 13 Dec '18

13 Dec '18

#15843: Tuple sections can't be quoted -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 are quite a few forms that are not supported in template haskell quotes. It seems that it would be at least a good warm up patch to add support for tuple sections which you can do simply by desugaring to a lambda and the normal tuple constructor. {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TupleSections #-} module Foo where foo = [|| (,5) ||] }}} 1. Modify `DsMeta.repE` to handle tuple sections. You can desugar `(,5) => `\x -> (x, 5)`. 2. Add the above test to the test suite. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15843> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function
by GHC 13 Dec '18

13 Dec '18

#1498: Optimisation: eliminate unnecessary heap check in recursive function -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: 4258 | Blocking: Related Tickets: 8326 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1498#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications?
by GHC 13 Dec '18

13 Dec '18

#15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | 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: -------------------------------------+------------------------------------- As a part of the work on moving some fragile analyses from Core to final phase before code gen (#9718) I found an unused analysis in CoreToStg which basically assigns each binder this: {{{ data StgBinderInfo = NoStgBinderInfo | SatCallsOnly -- All occurrences are *saturated* *function* calls -- This means we don't need to build an info table and -- slow entry code for the thing -- Thunks never get this value }}} The idea is , as mentioned in the comment, for `SatCallsOnly` binder we can avoid generating code for slow entry. However this is currently not used (see Phab:D5232), and this ticket is to decide whether to use or remove this. I found these comments in `StgCmmClosure` that explains how this became unused and how it was used before: {{{ ----------------------------------------------------------------------------- -- staticClosureRequired ----------------------------------------------------------------------------- {- staticClosureRequired is never called (hence commented out) SimonMar writes (Sept 07) It's an optimisation we used to apply at one time, I believe, but it got lost probably in the rewrite of the RTS/code generator. I left that code there to remind me to look into whether it was worth doing sometime {- Avoiding generating entries and info tables ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ At present, for every function we generate all of the following, just in case. But they aren't always all needed, as noted below: [NB1: all of this applies only to *functions*. Thunks always have closure, info table, and entry code.] [NB2: All are needed if the function is *exported*, just to play safe.] * Fast-entry code ALWAYS NEEDED * Slow-entry code Needed iff (a) we have any un-saturated calls to the function OR (b) the function is passed as an arg OR (c) we're in the parallel world and the function has free vars [Reason: in parallel world, we always enter functions with free vars via the closure.] * The function closure Needed iff (a) we have any un-saturated calls to the function OR (b) the function is passed as an arg OR (c) if the function has free vars (ie not top level) Why case (a) here? Because if the arg-satis check fails, UpdatePAP stuffs a pointer to the function closure in the PAP. [Could be changed; UpdatePAP could stuff in a code ptr instead, but doesn't seem worth it.] [NB: these conditions imply that we might need the closure without the slow-entry code. Here's how. f x y = let g w = ...x..y..w... in ...(g t)... Here we need a closure for g which contains x and y, but since the calls are all saturated we just jump to the fast entry point for g, with R1 pointing to the closure for g.] * Standard info table Needed iff (a) we have any un-saturated calls to the function OR (b) the function is passed as an arg OR (c) the function has free vars (ie not top level) NB. In the sequential world, (c) is only required so that the function closure has an info table to point to, to keep the storage manager happy. If (c) alone is true we could fake up an info table by choosing one of a standard family of info tables, whose entry code just bombs out. [NB In the parallel world (c) is needed regardless because we enter functions with free vars via the closure.] If (c) is retained, then we'll sometimes generate an info table (for storage mgr purposes) without slow-entry code. Then we need to use an error label in the info table to substitute for the absent slow entry code. -} staticClosureRequired :: Name -> StgBinderInfo -> LambdaFormInfo -> Bool staticClosureRequired binder bndr_info (LFReEntrant top_level _ _ _ _) -- It's a function = ASSERT( isTopLevel top_level ) -- Assumption: it's a top-level, no-free-var binding not (satCallsOnly bndr_info) staticClosureRequired binder other_binder_info other_lf_info = True -} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15770> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15858: Enabling a pure Plugin with existing build output never triggers recompilation
by GHC 12 Dec '18

12 Dec '18

#15858: Enabling a pure Plugin with existing build output never triggers recompilation -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following compilation session: {{{ $ ghc -fplugin ImpurePlugin Foo.hs <Compiles Foo.hs> $ ghc Foo.hs }}} where ImpurePlugin is a `Plugin` which returns `ForceRecompile` in `pluginRecompile`. The second invocation of GHC doesn't recompile even though `ImpurePlugin` could have changed the generated build output which would now be out of date. The same thing happens when switching from an impure/fingerprinted plugin to a pure plugin. The problem is that `pluginRecompileToRecompileRequired` just assumes no compilation is required when the current plugin stack is pure, that is either only pure plugins or no plugins at all are registered: {{{ pluginRecompileToRecompileRequired :: Fingerprint -> PluginRecompile -> RecompileRequired pluginRecompileToRecompileRequired old_fp pr = case pr of NoForceRecompile -> UpToDate ForceRecompile -> RecompBecause "Plugin forced recompilation" MaybeRecompile fp -> if fp == old_fp then UpToDate }}} note the `UpToDate` in the `NoForceRecompile` case. Furthermore I would argue that even switching from having no plugin at all active to having a pure plugin active should trigger recompilation, even though the plugin might be pure it could still choose to affect the build output after all. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15858> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16037: memcpy test inexplicably failing
by GHC 12 Dec '18

12 Dec '18

#16037: memcpy test inexplicably failing -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have started seeing failures in the `memcpy` test: {{{#!diff diff -uw "codeGen/should_gen_asm/memcpy.run/memcpy.asm.normalised" "codeGen/should_gen_asm/memcpy.run/memcpy.s.normalised" --- codeGen/should_gen_asm/memcpy.run/memcpy.asm.normalised 2018-12-11 23:13:18.763730758 -0500 +++ codeGen/should_gen_asm/memcpy.run/memcpy.s.normalised 2018-12-11 23:13:18.763730758 -0500 @@ -1,9 +1,9 @@ callMemcpy: +subq movq movq movl -subq -movl +xorl call memcpy addq jmp }}} The failures aren't themselves concerning; the new assembler is perfectly valid: {{{#!asm .section .text .align 8 .globl callMemcpy .type callMemcpy, @function callMemcpy: .Lc6: movl $1024,%eax subq $8,%rsp movq %rax,%rdx movq %rbx,%rdi movq %r14,%rsi xorl %eax,%eax call memcpy addq $8,%rsp jmp *(%rbp) .size callMemcpy, .-callMemcpy .section .note.GNU-stack,"",@progbits .ident "GHC 8.7.20181211" }}} However, I have no explanation for why this suddenly started happening. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16025: Makefiles bundled with source distribution fail to build cross-compiler.
by GHC 12 Dec '18

12 Dec '18

#16025: Makefiles bundled with source distribution fail to build cross-compiler. -------------------------------------+------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (make) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When trying to build a cross-compiler with GHC 8.6.3, I ran into the following: {{{ ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) libraries/ghc-prim/dist-install/build/GHC/CString.o: error adding symbols: File in wrong format echo libraries/ghc-prim/dist-install/build/GHC/CString.o libraries/ghc- prim/dist-install/build/GHC/Classes.o libraries/ghc-prim/dist- install/build/GHC/Debug.o libraries/ghc-prim/dist- install/build/GHC/IntWord64.o libraries/ghc-prim/dist- install/build/GHC/Magic.o libraries/ghc-prim/dist- install/build/GHC/PrimopWrappers.o libraries/ghc-prim/dist- install/build/GHC/Tuple.o libraries/ghc-prim/dist- install/build/GHC/Types.o libraries/ghc-prim/dist- install/build/cbits/atomic.o libraries/ghc-prim/dist- install/build/cbits/bswap.o libraries/ghc-prim/dist- install/build/cbits/clz.o libraries/ghc-prim/dist- install/build/cbits/ctz.o libraries/ghc-prim/dist- install/build/cbits/debug.o libraries/ghc-prim/dist- install/build/cbits/longlong.o libraries/ghc-prim/dist- install/build/cbits/pdep.o libraries/ghc-prim/dist- install/build/cbits/pext.o libraries/ghc-prim/dist- install/build/cbits/popcnt.o libraries/ghc-prim/dist- install/build/cbits/word2float.o >> libraries/ghc-prim/dist- install/build/libHSghc-prim-0.5.3.a.contents libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist- install/build/HSghc-prim-0.5.3.o' failed make[1]: *** [libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.o] Error 1 make[1]: *** Waiting for unfinished jobs.... "arm-linux-gnueabihf-ar" q libraries/ghc-prim/dist-install/build /libHSghc-prim-0.5.3.a @libraries/ghc-prim/dist-install/build/libHSghc- prim-0.5.3.a.contents arm-linux-gnueabihf-ar: creating libraries/ghc-prim/dist-install/build /libHSghc-prim-0.5.3.a "rm" -f libraries/ghc-prim/dist-install/build/libHSghc- prim-0.5.3.a.contents Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 It seems that this was due to an error in mk/config.mk, viz. LD_NO_GOLD = ld LD = arm-linux-gnueabihf-ld.gold NM = arm-linux-gnueabihf-nm AR = arm-linux-gnueabihf-ar OBJDUMP = arm-linux-gnueabihf-objdump }}} The variable {{{LD_NO_GOLD}}} should have the prefix {{{arm-linux- gnueabihf}}}. When I set {{{LD_NO_GOLD}}} to {{{arm-linux-gnueabihf-ld}}} manually, the build proceeds and works correctly. Let me know if you need any additional information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16025> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14551: GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules
by GHC 12 Dec '18

12 Dec '18

#14551: GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | 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: -------------------------------------+------------------------------------- Because of the way the GHCi defaults are applied, specifying `-XMonomorphismRestriction` or `-XNoExtendedDefaultRules` on the GHCi command line doesn't actually make those take effect at the interactive prompt. They get reset to their interactive defaults afterwards. This is rather surprising, and I think it should be fixed. One option is to dig through the parsed flags after setting the defaults to try to find these, but that sounds unpleasant. We're slowly accumulating hacks in this area, and it would be nice to find a better approach. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14551> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #3379: GHC should use the standard binary package
by GHC 12 Dec '18

12 Dec '18

#3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): Oh, quite so, thank you Ben! I [https://gitlab.staging.haskell.org/ulysses4ever/ghc/commit/a73488e420de3f69… fixed it] and now GHC compiles. I ran the test suite and had one unexpected failure (which I did not see before the patch): {{{ Unexpected results from: TEST="T14052" SUMMARY for test run started at Wed Dec 12 14:54:05 2018 UTC 0:52:39 spent to go through 6713 total tests, which gave rise to 20813 test cases, of which 13674 were skipped 45 had missing libraries 6936 expected passes 157 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 0 unexpected stat failures Unexpected failures: perf/should_run/T14052.run T14052 [[Errno 2] No such file or directory: 'perf/should_run/T14052.run/T14052.stats'] (ghci) }}} This feels strange. What should be the right way to investigate it? (I'm not super comfortable with the test suite). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3379#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates
by GHC 12 Dec '18

12 Dec '18

#15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Keywords: GHCProposal | 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 [https://github.com/ghc-proposals/ghc-proposals/pull/71 proposal] has been accepted, and could be implemented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15656> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13