August 2017 - ghc-tickets

[GHC] #14133: COMPLETE pragmas seem to be ignored when using view patterns
by GHC 17 Aug '17

17 Aug '17

#14133: COMPLETE pragmas seem to be ignored when using view patterns -------------------------------------+------------------------------------- Reporter: jle | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE ViewPatterns #-} {-# LANGUAGE PatternSynonyms #-} pattern I :: Int -> Int pattern I x <- (id -> x) {-# COMPLETE I #-} foo :: Int -> Int foo (I x) = x + 3 bar :: Int -> Int bar (id->I x) = x + 3 main :: IO () main = return () }}} Raises a warning for `bar`: {{{ Bug.hs:12:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for 'bar': Patterns not matched: _ | 12 | bar (id->(I x)) = x + 3 | ^^^^^^^^^^^^^^^^^^^^^^^ }}} but not for `foo`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14133> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #7960: Compiling profiling CCS registration .c file takes far too long
by GHC 17 Aug '17

17 Aug '17

#7960: Compiling profiling CCS registration .c file takes far too long -------------------------------------+------------------------------------- Reporter: duncan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7960#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10807: PatternGuards and MultiWayIf layout rules
by GHC 17 Aug '17

17 Aug '17

#10807: PatternGuards and MultiWayIf layout rules -------------------------------------+------------------------------------- Reporter: htebalaka | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The layout rules for MultiWayIf currently require any lines starting with a comma to be further indented than the lines starting with a pipe when used in conjunction with PatternGuards. This is inconsistent with the examples given in [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax- extns.html#pattern-guards]. For instance, we can't use the same indentation in the second example as in the first without triggering a parser error. {{{#!hs {-# LANGUAGE PatternGuards, MultiWayIf fine a pred | Just x <- a , pred x = True | otherwise = False notFine a pred = if | Just x <- a , pred x -> True | otherwise -> False }}} Though the documentation isn't ''incorrect'', if this intentional it could be pointed out, since it's counterintuitive. Otherwise, if there's no reason for MulitWayIf to require further indentation that should be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10807> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #7960: Compiling profiling CCS registration .c file takes far too long
by GHC 17 Aug '17

17 Aug '17

#7960: Compiling profiling CCS registration .c file takes far too long -------------------------------------------------+------------------------- Reporter: duncan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------------------+------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"a8da0de27e600211f04601ac737c329d6603c700/ghc" a8da0de2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a8da0de27e600211f04601ac737c329d6603c700" Speed up compilation of profiling stubs Here we encode the cost centre list as static data. This means that the initialization stubs are small functions which should be easy for GCC to compile, even with optimization. Fixes #7960. Test Plan: Test profiling Reviewers: austin, erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #7960 Differential Revision: https://phabricator.haskell.org/D3853 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7960#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14130: MultiWayIf parse behavior changed in 8.2.1
by GHC 17 Aug '17

17 Aug '17

#14130: MultiWayIf parse behavior changed in 8.2.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 (Parser) | 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: -------------------------------------+------------------------------------- I just noticed while working on Jenkins that ed7a830de6a2ea74dd6bb81f8ec55b9fe0b52f28 fails to build with GHC 8.0.1 with a parse error, yet succeeds with 8.2.1. The issue is demonstrated by the following program, {{{#!hs {-# LANGUAGE MultiWayIf #-} main = if | True -> putStrLn "hasdf" }}} Under GHC 8.0.1 this fails to compile with a parse error. Under 8.0.2 and 8.2.1 it parses without any trouble. We should sort out what the desired parse behavior for `MultiWayIf` is and add a test to ensure it doesn't change again. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14130> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #4385: Type-level natural numbers
by GHC 17 Aug '17

17 Aug '17

#4385: Type-level natural numbers -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Sounds good. Thanks yav! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4385#comment:79> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4385: Type-level natural numbers
by GHC 17 Aug '17

17 Aug '17

#4385: Type-level natural numbers -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 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 diatchki): I don't mind if you close it---we now have type-nats of sorts, we can open future tickets for various improvements of them, if they are needed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4385#comment:78> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14127: -fignore-interface-pragmas and -fspecialise do not go well together
by GHC 16 Aug '17

16 Aug '17

#14127: -fignore-interface-pragmas and -fspecialise do not go well together -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): corePrepPgm [True] $s$fSelectorMetaMetaSel_a = "_dconf_dump_annotations"# }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14127> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 16 Aug '17

16 Aug '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): Replying to [comment:84 hsyl20]: > I have just sketched a different proposal here: https://ghc.haskell.org/trac/ghc/wiki/StaticData > > IMO it is more generic and the different parts can be implemented independently. Note: Not all GHC have `TemplateHaskell`, especially stage 1 GHC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:85> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals
by GHC 16 Aug '17

16 Aug '17

#5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: thoughtpolice Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: strings Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5877 #10064 | Differential Rev(s): Phab:D2443 #11312, #9719 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): I have just sketched a different proposal here: https://ghc.haskell.org/trac/ghc/wiki/StaticData IMO it is more generic and the different parts can be implemented independently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5218#comment:84> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0