September 2013 - ghc-tickets

Re: [GHC] #8039: RTS linker: unloadObj() does not actually unload the code
by GHC 03 Sep '13

03 Sep '13

#8039: RTS linker: unloadObj() does not actually unload the code --------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: rts/linker_unload | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Comment (by heisenbug): I have pushed a new branch on my github ghc fork. It [https://github.com/ggreif/ghc/commit/206a4871a0e61f03668be5ed8f75faca603c13… contains just one commit], about unloading `dlopen`ed shared object files. It is actually untested, and non-windows. But it may be of use for doing what Simon did with unloading `.o` files in this ticket. Might be interesting to folks. Of course the GC must be wired up in a similar fashion, etc. Be careful. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8039#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7918: SrcSpan's associated with expanded quasi-quotes are inconsistent
by GHC 03 Sep '13

03 Sep '13

#7918: SrcSpan's associated with expanded quasi-quotes are inconsistent -----------------------------------------+--------------------------------- Reporter: edsko | Owner: edsko Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: quasiquotation/T7918 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -----------------------------------------+--------------------------------- Comment (by edsko): Note however that introducing `HsPar` and co will change the output of the pretty-printer, not sure if that will break regression tests. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7918#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7918: SrcSpan's associated with expanded quasi-quotes are inconsistent
by GHC 03 Sep '13

03 Sep '13

#7918: SrcSpan's associated with expanded quasi-quotes are inconsistent -----------------------------------------+--------------------------------- Reporter: edsko | Owner: edsko Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: quasiquotation/T7918 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -----------------------------------------+--------------------------------- Comment (by edsko): So actually I agreed with you that the special case was undesirable, which is why I had (for types, not yet for expressions) got rid of rnHsType completely, and defined only rnLHsType. This way the exceptions you mention are taken care off statically, which is much better. Your suggestion is an alternative; I thought about it but I thought I'd need to add a new constructor to HsExpr/HsType/Pat/..; didn't realize that I could use the constructor for parens. Do you prefer I use HsPar and co instead of removing rnHsExpr (rnHsType, ..)? It certainly would be a less intrusive change I guess. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7918#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7918: SrcSpan's associated with expanded quasi-quotes are inconsistent
by GHC 03 Sep '13

03 Sep '13

#7918: SrcSpan's associated with expanded quasi-quotes are inconsistent -----------------------------------------+--------------------------------- Reporter: edsko | Owner: edsko Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: quasiquotation/T7918 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -----------------------------------------+--------------------------------- Comment (by simonpj): (I wrote this comment yesterday, but it has disappeared. Sigh.) Edsko, putting a special case in `rnLExpr` is a bit undesirable because: * It makes `rnLExpr` more than a dispactch to `rnExpr` * It means that `rnExpr` will never see a `HsQuasiQuoteE`, so it is "missing a case"; there's an invariant that the `HsQuasiQuoteE` case never occurs * It's fragile, because there might be ''other'' calls to `rnExpr` that don't satisfy that invariant. Here's an alternative. Replace {{{ rnExpr (HsQuasiQuoteE qq) = runQuasiQuoteExpr qq `thenM` \ (L _ expr') -> rnExpr expr' }}} with {{{ rnExpr (HsQuasiQuoteE qq) = runQuasiQuoteExpr qq `thenM` \ lexpr' -> rnExpr (HsPar lexpr') }}} Here I'm wrapping the returned expression in parens (which is probably a reasonable idea if we ever want to display the result of expanding quasiquotes), and that makes the types work out ok. The location on `lexpr'` will correctly be handled by the call to `rnLExpr` in the `HsPar` case of `rnExpr`. Would that work? Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7918#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7918: SrcSpan's associated with expanded quasi-quotes are inconsistent
by GHC 03 Sep '13

03 Sep '13

#7918: SrcSpan's associated with expanded quasi-quotes are inconsistent -----------------------------------------+--------------------------------- Reporter: edsko | Owner: edsko Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: quasiquotation/T7918 | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -----------------------------------------+--------------------------------- Changes (by edsko): * testcase: => quasiquotation/T7918 Comment: Second overwrite for types turned out to be caused by the handling for foralls. Changed this and added a note. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7918#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7633: Checkable "minimal complete definitions"
by GHC 03 Sep '13

03 Sep '13

#7633: Checkable "minimal complete definitions" -------------------------------------+------------------------------------ Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #6028 -------------------------------------+------------------------------------ Comment (by simonpj): Twan did an implementation, and there was some ensuing discussion (above) about * The design * Aspects of the implementation * In the end it needs documentation and tests I think it's a useful feature, but it needs someone to run with it. I'm sure Twan wouldn't mind if someone took up when he left off. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7633#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8215: Out of scope with `-dcore-lint` and derived instances in GHCi
by GHC 03 Sep '13

03 Sep '13

#8215: Out of scope with `-dcore-lint` and derived instances in GHCi ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- At revision 9e2e84e01cbf2bc1da1fc7260709f63687206d76 (current HEAD), I observe this failure: {{{ $ ./inplace/bin/ghc-stage2 --interactive GHCi, version 7.7.20130902: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> newtype Age = Age Int deriving Show Prelude> newtype Bar = Bar Age deriving Show Prelude> Bar (Age 1)) <interactive>:4:12: parse error on input `)' Prelude> Bar (Age 1) Bar (Age 1) Prelude> Leaving GHCi. [jojo@kirk:3] Mo, der 02.09.2013 um 16:47 Uhr Keep Smiling :-) ~/build/haskell/ghc $ ./inplace/bin/ghc-stage2 --interactive -dcore-lint GHCi, version 7.7.20130902: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> newtype Age = Age Int deriving Show Prelude> newtype Bar = Bar Age deriving Show *** Core Lint errors : in result of Desugar (after optimization) *** <no location info>: Warning: In the expression: GHC.Show.showsPrec @ :Interactive.Age :Interactive.$fShowAge (GHC.Types.I# 11) (ds_dq3 `cast` (:Interactive.NTCo:Bar[0] :: :Interactive.Bar ~# :Interactive.Age)) :Interactive.$fShowAge :: GHC.Show.Show :Interactive.Age [LclIdX[DFunId], Str=DmdType] is out of scope *** Offending Program *** Rec { $cshowsPrec_apH :: GHC.Types.Int -> :Interactive.Bar -> GHC.Show.ShowS [LclId, Str=DmdType] $cshowsPrec_apH = \ (a_apF :: GHC.Types.Int) (ds_dq3 :: :Interactive.Bar) -> GHC.Show.showParen (GHC.Classes.>= @ GHC.Types.Int GHC.Classes.$fOrdInt a_apF (GHC.Types.I# 11)) (GHC.Base.. @ GHC.Base.String @ GHC.Base.String @ GHC.Base.String (GHC.Show.showString (GHC.CString.unpackCString# "Bar "#)) (GHC.Show.showsPrec @ :Interactive.Age :Interactive.$fShowAge (GHC.Types.I# 11) (ds_dq3 `cast` (:Interactive.NTCo:Bar[0] :: :Interactive.Bar ~# :Interactive.Age)))) :Interactive.$fShowBar [InlPrag=[ALWAYS] CONLIKE] :: GHC.Show.Show :Interactive.Bar [LclIdX[DFunId], Str=DmdType, Unf=DFun: \ -> GHC.Show.D:Show TYPE :Interactive.Bar $cshowsPrec_apH $cshow_apS $cshowList_apU] :Interactive.$fShowBar = GHC.Show.D:Show @ :Interactive.Bar $cshowsPrec_apH $cshow_apS $cshowList_apU $cshowList_apU [Occ=LoopBreaker] :: [:Interactive.Bar] -> GHC.Show.ShowS [LclId, Str=DmdType] $cshowList_apU = GHC.Show.showList__ @ :Interactive.Bar (GHC.Show.showsPrec @ :Interactive.Bar :Interactive.$fShowBar (GHC.Types.I# 0)) $cshow_apS [Occ=LoopBreaker] :: :Interactive.Bar -> GHC.Base.String [LclId, Str=DmdType] $cshow_apS = GHC.Show.$dmshow @ :Interactive.Bar :Interactive.$fShowBar end Rec } *** End of Offense *** <no location info>: Compilation had errors *** Exception: ExitFailure 1 }}} I do not observe this in GHC. I’ll write a test case for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8215> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8217: Cross-compiling: Use CrossCompilePrefix for libdir
by GHC 03 Sep '13

03 Sep '13

#8217: Cross-compiling: Use CrossCompilePrefix for libdir -------------------------------------------+------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: 7724 -------------------------------------------+------------------------------- As suggested by Gabor Grief, use the CrossCompilePrefix when installing GHC libraries. http://www.haskell.org/pipermail/ghc-devs/2013-September/002251.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8217> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8216: Segment fault using TH
by GHC 02 Sep '13

02 Sep '13

#8216: Segment fault using TH ------------------------------------+------------------------------------- Reporter: klrr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: segment fault th | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hey, I was asked on reddit to report this as it was a bug. :-) When I try compile this code https://gist.github.com/klrr/6414202 (one of the acid-state examples) I get this error/Segment fault https://gist.github.com/klrr/6414605 The problem seem to be on line 19 "$(deriveSafeCopy 0 'base ''HelloWorldState)" that makes me think it's some issue with TH. Also, while I'm here, I'm sorry for my previous actions on #haskell, I wanna contribute and help Haskell community not be annoying and in the way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8216> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7633: Checkable "minimal complete definitions"
by GHC 02 Sep '13

02 Sep '13

#7633: Checkable "minimal complete definitions" -------------------------------------+------------------------------------ Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #6028 -------------------------------------+------------------------------------ Changes (by hvr): * related: 6028 => #6028 Comment: This ticket seems stalled; would be nice to have this in 7.8.1 though :-) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7633#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0