December 2014 - ghc-tickets

Re: [GHC] #4896: Deriving Data does not work for attached code
by GHC 02 Dec '14

02 Dec '14

#4896: Deriving Data does not work for attached code -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_compile/T4896 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by dreixel): Looks good to me! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4896#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4896: Deriving Data does not work for attached code
by GHC 02 Dec '14

02 Dec '14

#4896: Deriving Data does not work for attached code -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_compile/T4896 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"863854a3a490afd9e3ecf0da6294a3b078f4a6a1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="863854a3a490afd9e3ecf0da6294a3b078f4a6a1" Fix another bug in deriving( Data ) for data families; Trac #4896 If we have data family D a data instance D (a,b,c) = ... deriving( Data ) then we want to generate instance ... => Data (D (a,b,c)) where ... dataCast1 x = gcast1 x The "1" here comes from the kind of D. But the kind of the *representation* TyCon is data Drep a b c = .... ie Drep :: * -> * -> * -> * So we must look for the *family* TyCon in this (rather horrible) dataCast1 / dataCast2 binding. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4896#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances
by GHC 02 Dec '14

02 Dec '14

#2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.9 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: T2182ghci, | T2182ghci2, T2182 | Blocking: | Differential Revisions: Phab:D488 | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"2a67fb3990f23391fecaec335f0d010434d2738e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2a67fb3990f23391fecaec335f0d010434d2738e" Minor refactoring of Edward's recent orphans patch (Trac #2182) This patch is all small stuff - Move VisibleOrphanModules from Module to InstEnv (with the other orphan stuff) - Move Notes about orphans from IfaceSyn to InstEnv (ditto) - Make use of the record field names in InstEnvs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2182#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4921: report ambiguous type variables more consistently
by GHC 02 Dec '14

02 Dec '14

#4921: report ambiguous type variables more consistently -------------------------------------+------------------------------------- Reporter: Saizan | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: low | Version: 7.0.1 Component: Compiler | Keywords: (Type checker) | Architecture: Unknown/Multiple Resolution: | Difficulty: Unknown Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"30d260586d46466419b109057ec87d4f097331a1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="30d260586d46466419b109057ec87d4f097331a1" Test Trac #4921 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4921#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4896: Deriving Data does not work for attached code
by GHC 02 Dec '14

02 Dec '14

#4896: Deriving Data does not work for attached code -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | deriving/should_compile/T4896 | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: dreixel (added) * testcase: => deriving/should_compile/T4896 Comment: The error message for mojojojo is exactly right. The error message from HEAD for the original example is actually a long- standing bug; quite a different one from the one originally reported. This code should compile. Good catch, thank you Tomie! Patch coming. Pedro, can you just check that I have done this right? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4896#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon`
by GHC 02 Dec '14

02 Dec '14

#9812: Split `SynTyCon` into `SynonymTyCon` and `FamilyTyCon` -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- As part of my work on #6018 I added new fields to `SynTyCon` data constructor of `TyCon` type. These fields only make sense for type families because we don't trace injectivity information for type synonyms. `SynTyCon` already has some fields that only make sense for type families. Richard suggests that `SynTyCon` is split into two separate constructors. With my implementation of injective type families this makes even more changes. I'm going to make that change in HEAD Real Soon Now so that I can rebase my work on top of it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9812> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #4121: Refactor the plumbing of CafInfo to make it more robust
by GHC 02 Dec '14

02 Dec '14

#4121: Refactor the plumbing of CafInfo to make it more robust -------------------------------------+------------------------------------- Reporter: dterei | Owner: Type: task | Status: new Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I've added it to my list, because it does indeed need attention. I think the right thing is to extract the information during the core-to- STG pass, and back-patch it into the interface-file info. The difficulty is really just ensuring that we don't thereby make space behaviour a lot worse by, in effect, having two copies of the program in memory at once. I'd welcome help with doing this. Not hard, but needs a bit of care. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4121#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4428: Local functions lose their unfoldings
by GHC 02 Dec '14

02 Dec '14

#4428: Local functions lose their unfoldings -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: infoneeded Priority: low | Milestone: 7.10.1 Component: Compiler | Version: 7.1 Resolution: | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: Runtime | Blocked By: performance bug | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Comment (by simonpj): I believe it's fixed; or at least some things were done, and the subsequent discussion is inconclusive. I'm inclined to close it if no one objects. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4428#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7647: UNPACK polymorphic fields
by GHC 02 Dec '14

02 Dec '14

#7647: UNPACK polymorphic fields -------------------------------------+------------------------------------- Reporter: liyang | Owner: Type: feature | Status: new request | Milestone: 7.10.1 Priority: normal | Version: 7.6.1 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: Runtime | Related Tickets: 3990 performance bug | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: simonpj => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7647#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances
by GHC 02 Dec '14

02 Dec '14

#2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances -------------------------------------+------------------------------------- Reporter: claus | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 6.9 (Type checker) | Keywords: Resolution: fixed | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: GHC | Related Tickets: accepts invalid program | Test Case: T2182ghci, | T2182ghci2, T2182 | Blocking: | Differential Revisions: Phab:D488 | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * testcase: => T2182ghci, T2182ghci2, T2182 * resolution: => fixed Comment: Already did. :) T2182ghci, T2182ghci2, T2182. I'll add them to the ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2182#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0