- ghc-tickets - Haskell.org

Re: [GHC] #3314: Add compilation date to +RTS --info
by GHC 20 Aug '16

20 Aug '16

#3314: Add compilation date to +RTS --info -------------------------------------+------------------------------------- Reporter: Orphi | Owner: ak3n Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2460 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ak3n): * owner: => ak3n * failure: => None/Unknown * differential: => Phab:D2460 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3314#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12501: Windows builds segfault (as in doesn't work at all).
by GHC 19 Aug '16

19 Aug '16

#12501: Windows builds segfault (as in doesn't work at all). -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.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: -------------------------------------+------------------------------------- Commit a9bc54766ddd1bdb011f1656ad58fb409055d08f is the last known good commit for the Windows build of GHC. After this point multiple segfaults were introduced due to changes in the rts and GC. One was introduced by the compacts regions patch cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453 but fixed by f9a11a241b8056ac2b9c771172a48919fb3d0ed1 Unfortunately because many of the intermediate commits between cf989ffe490c146be4ed0fd7e0c00d3ff8fe1453 also break the build I can't run a proper bisect. And because of some very large commits in between it makes it really hard to cherry-pick individual commits or rebase certain ones out manually to try. Effectively something was committed that makes GC go horribly wrong. {{{ Tamar@Kino MINGW64 ~/ghc2 $ inplace/bin/ghc-stage2.exe --version The Glorious Glasgow Haskell Compilation System, version 8.1.20160817 Segmentation fault }}} In GDB {{{ Program received signal SIGSEGV, Segmentation fault. 0x0000000002aa35d9 in LOOKS_LIKE_CLOSURE_PTR (p=0x2cd1dd000000000) at includes/rts/storage/ClosureMacros.h:275 275 (UNTAG_CONST_CLOSURE((const StgClosure *)(p)))->header.info); (gdb) bt #0 0x0000000002aa35d9 in LOOKS_LIKE_CLOSURE_PTR (p=0x2cd1dd000000000) at includes/rts/storage/ClosureMacros.h:275 #1 0x0000000002aa3e3e in evacuate1 (p=0x31c1a04 <S4UR_srt+4>) at rts\sm\Evac.c:416 #2 0x0000000002a7a183 in scavenge_srt (srt=0x31c1a04 <S4UR_srt+4>, srt_bitmap=1) at rts\sm\Scav.c:351 #3 0x0000000002a7a253 in scavenge_fun_srt (info=0x278dfb0 <c1Fi_info+88>) at rts\sm\Scav.c:390 #4 0x0000000002a7c245 in scavenge_static () at rts\sm\Scav.c:1747 #5 0x0000000002a7c8f2 in scavenge_loop1 () at rts\sm\Scav.c:2081 #6 0x0000000002a722bb in scavenge_until_all_done () at rts\sm\GC.c:968 #7 0x0000000002a71008 in GarbageCollect (collect_gen=1, do_heap_census=rtsFalse, gc_type=2, cap=0x320f5c0 <MainCapability>) at rts\sm\GC.c:403 #8 0x0000000002a61856 in scheduleDoGC (pcap=0x3b4fbb8, task=0x6c6e0d0, force_major=rtsFalse) at rts\Schedule.c:1797 #9 0x0000000002a5fb68 in schedule (initialCapability=0x320f5c0 <MainCapability>, task=0x6c6e0d0) at rts\Schedule.c:552 #10 0x0000000002a62355 in scheduleWaitThread (tso=0x7205b98, ret=0x0, pcap=0x3b4fd40) at rts\Schedule.c:2494 #11 0x0000000002a4e24a in rts_evalLazyIO (cap=0x3b4fd40, p=0x2aabad0 <ZCMain_main_closure>, ret=0x0) at rts\RtsAPI.c:500 #12 0x0000000002a4d350 in hs_main (argc=1, argv=0x6c640b0, main_closure=0x2aabad0 <ZCMain_main_closure>, rts_config=...) at rts\RtsMain.c:64 #13 0x00000000004b4c75 in main () }}} It seems that all `info` tables are messed up. In `frame #4` the table contains very suspicious values: {{{ (gdb) frame 4 #4 0x0000000002a7c245 in scavenge_static () at rts\sm\Scav.c:1747 1747 scavenge_fun_srt(info); (gdb) p info $3 = (const StgInfoTable *) 0x278dfb0 <c1Fi_info+88> (gdb) pinfo info $4 = {layout = {payload = {ptrs = 10697284, nptrs = 0}, bitmap = 10697284, large_bitmap_offset = 10697284, __pad_large_bitmap_offset = 10697284, selector_offset = 10697284}, type = 3, srt_bitmap = 1, code = 0x278dfb0 <c1Fi_info+88> ""} }}} Unfortunately my knowledge of GHC's `GC` is severely lacking at this moment so I have no idea how to debug this effectively and without knowing the commit that introduced it's rather slow going. Any help or hints appreciated. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12501> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12500: Open Type Family Kind Resolution
by GHC 19 Aug '16

19 Aug '16

#12500: Open Type Family Kind Resolution -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 is a minimal example of this problem: {{{#!hs -- Section 1 data Animal = Dog | Cat | Mouse data Planet = Earth | Jupiter | Mars | Saturn type family ToRes (k :: Type) = (j :: Type) type instance ToRes Planet = Animal -- Section 2 type family Thing k (a :: k) = (b :: ToRes k) type instance Thing Planet 'Earth = 'Dog }}} The last line fails with: {{{ Expected kind 'ToRes Planet', but 'Dog has kind Animal }}} What's weird is that, if I take the part labeled Section 1 and move it into another module and then import that module into one that contains Section 2, it compiles fine. In this minimal case, that's not a huge problem, but for my real use case, splitting the type instances into two modules like this forces me to use an orphan. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12500> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #2893: Implement "Quantified contexts" proposal
by GHC 19 Aug '16

19 Aug '16

#2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal 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) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2893#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5927: A type-level "implies" constraint on Constraints
by GHC 19 Aug '16

19 Aug '16

#5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Use case from [http://ozark.hendrix.edu/~yorgey/pub/twisted.pdf How to Twist Pointers without Breaking Them]: > {{{#!hs > class Monoid m => Action m a where > act :: m -> a -> a > }}} > ''[...]'' > > We first formalise the action of monoids on functors. Intuitively, for a monoid `m` to act on the functor `f`, it should act in a uniform way on all the types `f a`. Therefore, we would like to assert a constraint something like `forall a. Action m (f a)`. Unfortunately, Haskell does not allow the use of universally quantified constraints and hence we need a new type class. > > {{{#!hs > class (Monoid m, Functor f) => ActionF m f where > act' :: m -> f a -> f a > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5927#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 19 Aug '16

19 Aug '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * milestone: => 8.2.1 Comment: This will be finished by `8.2.1` (probably earlier as well). Though it requires some thinking about how the bindist should go. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:60> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12493: Add gcoerceWith to Data.Type.Coercion
by GHC 18 Aug '16

18 Aug '16

#12493: Add gcoerceWith to Data.Type.Coercion -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: | Version: 8.0.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: -------------------------------------+------------------------------------- Haskell libraries mailing list discussion: https://mail.haskell.org/pipermail/libraries/2016-July/027207.html > In Data.Type.Equality, we have both > > {{{#!hs > castWith :: (a :~: b) -> a -> b > }}} > > and > > {{{#!hs > gcastWith :: (a :~: b) -> (a ~ b => r) -> r > }}} > > > But in `Data.Type.Coercion` we only have > > {{{#!hs > coerceWith :: Coercion a b -> a -> b > }}} > > It seems to me that for the sake of consistency, we should add > > {{{#!hs > gcoerceWith :: Coercion a b -> (Coercible a b => r) -> r > gcoerceWith Coercion a = a > }}} > > David Feuer I've wanted this too. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12493> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8955: Syscall intrinsic
by GHC 18 Aug '16

18 Aug '16

#8955: Syscall intrinsic ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- Reddit thread: http://www.reddit.com/r/haskell/comments/220ae4/libc_considered_harmful/ Mentions there are some nice things that can be done with a syscall intrinsic. Also, marginally increased speed for calling syscalls since it doesn't need to go through libffi into C-land. Should be easy to implement. llvm backend has `llvm.syscall` already. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8955> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #393: functions without implementations
by GHC 18 Aug '16

18 Aug '16

#393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: None checker) | 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 Iceland_jack): Unpolished ideas: use `djinn`, [https://mail.haskell.org/pipermail /haskell-cafe/2015-April/119385.html Exference] or any other [http://www.cis.upenn.edu/~stevez/papers/OZ15.pdf program synthesiser]) to supply the function body {{{#!hs {-# SYNTHESISE id #-} id :: forall a. a -> a }}} would be as if the user had written {{{#!hs id :: forall a. a -> a id x = x }}} Perhaps this could be implemented using plugin + annotations, I'm not familiar with the details: {{{#!hs {-# ANN f Exference #-} f :: Show b => (a -> b) -> [a] -> [String] }}} producing {{{#!hs f :: Show b => (a -> b) -> [a] -> [String] f b = fmap (\g -> show (b g)) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/393#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12432: TypeInType: open type family application as type family return kind fails to compile
by GHC 18 Aug '16

18 Aug '16

#12432: TypeInType: open type family application as type family return kind fails to compile -------------------------------------+------------------------------------- Reporter: j6carey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Linux Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With TypeInType enabled, I can use a closed type family to compute the return kind of a type family from its arguments. But an equivalent open type family used in the same way triggers a compilation failure, as if the relevant instance of that open type family were not considered. (Of course, there may be some subtle prohibition of which I am not aware at the present time.) I will attach a test case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12432> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14