February 2013 - ghc-tickets

[GHC] #7671: No break spaces
by GHC 26 Feb '13

26 Feb '13

#7671: No break spaces -----------------------------+---------------------------------------------- Reporter: zenzike | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I thought I was going mad when the following code wasn't compiling: {{{ {-# LANGUAGE UnicodeSyntax #-} {-# LANGUAGE RankNTypes #-} type F f = forall x . f x }}} GHC was producing the following error message: {{{ mad.hs:4:21 Illegal symbol '.' in type Perhaps you intended -XRankNTypes or similar flag to enable explicit-forall syntax: forall <tvs>. <type> }}} It turns out that I had somehow inserted a unicode no break space, character code `U+00a0`, in the line importing RankNTypes, just after the first `#`. Baffling. This begs the question: should GHC treat this unicode space as an ordinary space when the `UnicodeSyntax` extension is enabled? If not should there have been some warning that I had inserted this symbol in a language pragma? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7627: Space in nullary unboxed tuples
by GHC 25 Feb '13

25 Feb '13

#7627: Space in nullary unboxed tuples -----------------------------+---------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- {{{ Prelude> :t (# #) (# #) :: (##) }}} should be {{{ (# #) :: (# #) }}} - the syntax requires a space. I apologise for raising such a trivial matter. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7627> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 25 Feb '13

25 Feb '13

#6084: Add stg_ap_pnnv and related call patterns ---------------------------------+------------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): Yes the extra call patterns take up RTS code space, but that's an extremely minor matter -- and they do a good job for under and over- saturated calls as well as exactly-saturated ones. I'm all for your fix in addition, for the case where there is no RTS pattern. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6084#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 25 Feb '13

25 Feb '13

#6084: Add stg_ap_pnnv and related call patterns ---------------------------------+------------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonmar): I don't think they're orthogonal: both ways avoid building the intermediate PAP(s). The tradeoffs are: * with extra call patterns, we have to predict which patterns we need, and we can easily get it wrong (e.g. we're talking here about needing `ppnnnv`, which is quite obscure) * extra call patterns take up static code space in the RTS whether we use them or not. * Generating the saturation check at the call site means extra code, but it works for any pattern, and you don't pay for it if you don't need it (the case in the codegen was not triggered at all in nofib, and was only triggered once in the codeGen tests, unless I did something wrong). The short-cut isn't the same as generating a fresh slow-call pattern at the call site. It only does the saturation check, and delegates everything else to the existing slow call patterns. I think it should be exactly what's needed in these cases, but I'd like to see some benchmarks. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6084#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5391: Better deriving for Typeable
by GHC 25 Feb '13

25 Feb '13

#5391: Better deriving for Typeable -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.0.4 Resolution: wontfix | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Yes, the polykinded Typeable is strictly better than the compromise offered here. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5391#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6084: Add stg_ap_pnnv and related call patterns
by GHC 25 Feb '13

25 Feb '13

#6084: Add stg_ap_pnnv and related call patterns ---------------------------------+------------------------------------------ Reporter: SimonMeier | Owner: simonmar Type: feature request | Status: infoneeded Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj): Wouldn't adding new call patterns ''also'' be a good idea? The "short- cut" idea simply catches the case where the call is (dynamically) saturated; it doesn't obviate the desirability of having various slow-call patterns. The two ideas seem orthogonal to me. Simon -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6084#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7682: Plugin example not updated for ghc 7.6
by GHC 24 Feb '13

24 Feb '13

#7682: Plugin example not updated for ghc 7.6 -----------------------------+---------------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The GHC plugin docs (http://www.haskell.org/ghc/docs/latest/html/users_guide/compiler- plugins.html) have this example: {{{ pass :: ModGuts -> CoreM ModGuts pass = bindsOnlyPass (mapM printBind) where printBind :: CoreBind -> CoreM CoreBind printBind bndr@(NonRec b _) = do putMsgS $ "Non-recursive binding named " ++ showSDoc (ppr b) return bndr printBind bndr = return bndr }}} but in ghc >= 7.6 `showSDoc` requires `DynFlags`: {{{ pass :: ModGuts -> CoreM ModGuts pass guts = do dynFlags <- getDynFlags bindsOnlyPass (mapM $ printBind dynFlags) guts where printBind :: DynFlags -> CoreBind -> CoreM CoreBind printBind _dynFlags bndr@(NonRec b _) = do #if __GLASGOW_HASKELL__ >= 706 putMsgS $ "Non-recursive binding named " ++ showSDoc _dynFlags (ppr b) #else putMsgS $ "Non-recursive binding named " ++ showSDoc (ppr b) #endif return bndr printBind _dynFlags bndr = return bndr }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7682> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #2507: quotation characters in error messages
by GHC 24 Feb '13

24 Feb '13

#2507: quotation characters in error messages -------------------------------+-------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: #2811,#3398 -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Done -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2507#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2507: quotation characters in error messages
by GHC 24 Feb '13

24 Feb '13

#2507: quotation characters in error messages ---------------------------------+------------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #2811,#3398 | ---------------------------------+------------------------------------------ Comment(by ian@…): commit e2bea6019fd523d4b6061174b114c49f55fa981c {{{ Author: Ian Lynagh <ian(a)well-typed.com> Date: Sun Feb 24 00:26:07 2013 +0000 Use unicode quote characters in error messages etc; fixes #2507 We only use the unicode characters if the locale supports them. compiler/main/DynFlags.hs | 15 ++++++++++++++- compiler/main/DynFlags.hs-boot | 1 + compiler/utils/Outputable.lhs | 7 ++++++- 3 files changed, 21 insertions(+), 2 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2507#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2467: orphan instance warnings are badly behaved
by GHC 24 Feb '13

24 Feb '13

#2467: orphan instance warnings are badly behaved -------------------------------+-------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Resolution: fixed | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I don't think there are any more concrete changes we want to make, and there's been no discussion for years, so closing this ticket. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2467#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0