December 2016 - ghc-tickets

[GHC] #12767: Pattern synonyms for Cont, Writer, Reader, State, ...
by GHC 01 Jan '17

01 Jan '17

#12767: Pattern synonyms for Cont, Writer, Reader, State, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12001 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Made this its own ticket, rather than using #12001. Are these worth adding? {{{#!hs pattern Cont :: ((a -> r) -> r) -> Cont r a pattern Cont a <- (runCont -> a) where Cont a = cont a pattern Writer :: (a, w) -> Writer w a pattern Writer a <- (runWriter -> a) where Writer a = WriterT (Identity a) pattern Reader :: (r -> a) -> Reader r a pattern Reader a <- (runReader -> a) where Reader a = reader a pattern State :: (s -> (a, s)) -> State s a pattern State a <- (runState -> a) where State a = state a }}} The mtl API was changed way back when (before advent of pattern synonyms) which caused some [http://stackoverflow.com/questions/14157090/has-the- control-monad-state-api-changed-recently confusion], [http://learnyouahaskell.com/for-a-few-monads-more LYAH] still uses `Writer`, `State` in their examples. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12767> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13047: Can create bindings of kind Constraint without ConstraintKind, only TypeFamilies
by GHC 31 Dec '16

31 Dec '16

#13047: Can create bindings of kind Constraint without ConstraintKind, only TypeFamilies -------------------------------------+------------------------------------- Reporter: pggiarrusso | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- This code compiles with GHC 8.0.1 (in either variant, with or without the definition of ApplyCtx Int in Foo Int. I think it shouldn't according to the docs in http://ghc.readthedocs.io/en/master/glasgow_exts.html?highlight=constraintK… #the-constraint-kind. If this is intended, I guess documenting it is acceptable. {{{ {-# LANGUAGE TypeFamilies #-} module Foo where import GHC.Exts (Constraint) class Foo a where type ApplyCtx a :: Constraint type ApplyCtx a = () instance Foo Int where type ApplyCtx Int = Show Int -- Commenting this out makes no difference. f :: ApplyCtx Int => Int f = 0 }}} Googling found https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-February/026151.html, but seems a different issue (and a non- bug). Also found https://ghc.haskell.org/trac/ghc/ticket/11715, which might be relevant (or not). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13047> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7647: UNPACK polymorphic fields
by GHC 31 Dec '16

31 Dec '16

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

1 0

Re: [GHC] #5075: CPR optimisation for sum types if only one constructor is used
by GHC 31 Dec '16

31 Dec '16

#5075: CPR optimisation for sum types if only one constructor is used -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Related: Phab:D2436 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5075#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #605: Optimisation: strict enumerations
by GHC 31 Dec '16

31 Dec '16

#605: Optimisation: strict enumerations -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: Related Tickets: #6135 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): FWIW we can currently store strict enumerations as `Int#`s with Phab:D2424. Phab:D2436 allows returning `Int#` when returned enumeration is used strictly. Another patch is needed for extending demand analysis and passing `Int#` for strict enumerations. I actually have most of the code ready, but it needs rebasing it on current HEAD. IIRC some parts of the demand analysis were missing, but I can't remember exactly which parts. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/605#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles
by GHC 30 Dec '16

30 Dec '16

#7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.1-rc1 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 joeyhess): And here is the segfault info: {{{ *** Error in `./foo': double free or corruption (top): 0x0000000000b7b620 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f042ba4bbcb] /lib/x86_64-linux-gnu/libc.so.6(+0x76fa6)[0x7f042ba51fa6] /lib/x86_64-linux-gnu/libc.so.6(+0x7779e)[0x7f042ba5279e] /lib/x86_64-linux-gnu/libc.so.6(+0x21226)[0x7f042b9fc226] /lib/x86_64-linux-gnu/libc.so.6(iconv_close+0xf)[0x7f042b9fbabf] ./foo[0x40ef80] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7161#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles
by GHC 30 Dec '16

30 Dec '16

#7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.1-rc1 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 joeyhess): I reproduced this bug in the wild today. Here is my test case: import GHC.IO.Encoding import System.IO main = do e <- getFileSystemEncoding hClose stdin hSetEncoding stdin e ghc 8.0.1 on Linux. For me, the crash only occurs with LANG=C. With my usual locale of en_US.utf8 there is no crash. Perhaps this is why there was a problem reproducing it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7161#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13046: TH Names can't be used in patterns
by GHC 30 Dec '16

30 Dec '16

#13046: TH Names can't be used in patterns -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | 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: -------------------------------------+------------------------------------- Here's an example where I try to use a `Name` (with double ticks) as a pattern: {{{#!hs {-# LANGUAGE TemplateHaskell #-} foo :: Name -> () foo ''Int = () }}} It fails with this error: {{{#!text test.hs:4:5-9: Parse error in pattern: ''Int }}} Seems like a bug to me (if we can compare `Name`s, why can't we pattern- match on them?). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13046> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13045: LLVM code generation causes segfaults on FreeBSD
by GHC 30 Dec '16

30 Dec '16

#13045: LLVM code generation causes segfaults on FreeBSD ---------------------------------------+--------------------------------- Reporter: emc2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.2 Keywords: | Operating System: FreeBSD Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+--------------------------------- Steps to reproduce: 1. Install lang/ghc from ports, select LLVM option 1. Install devel/hs-cabal-install from ports, select LLVM option on all Haskell packages 1. Attempt to run cabal update This was seemingly introduced in 7.10.* The FreeBSD ports based on 7.8.3 worked perfectly with LLVM. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #2607: Inlining defeats selector thunk optimisation
by GHC 29 Dec '16

29 Dec '16

#2607: Inlining defeats selector thunk optimisation -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12241 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #12241 Comment: #12241 provides another example of the selector thunk trick being defeated by the simplifier. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2607#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0