- ghc-tickets - Haskell.org

[GHC] #12087: Inconsistency in GADTs?
by GHC 17 Aug '17

17 Aug '17

#12087: Inconsistency in GADTs? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: GADTs | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs f :: Ord a => Eq a => a -> Bool f = … }}} this is allowed but not in GADTs {{{#!hs data F a where MkF :: Ord a => Eq a => a -> F a -- <interactive>:48:16: error: -- • Data constructor ‘MkF’ returns type ‘Eq a => a -> F a’ -- instead of an instance of its parent type ‘F a’ -- • In the definition of data constructor ‘MkF’ -- In the data type declaration for ‘F’ }}} not a big deal -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12087> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14134: Implement enums for Cmm
by GHC 17 Aug '17

17 Aug '17

#14134: Implement enums for Cmm -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: (CodeGen) | 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: -------------------------------------+------------------------------------- Using ANSI C enums is documented as a preferred way of defining constants: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Conventions#Syntacticd… Basically instead of writing: {{{ #define INVALID_OBJECT 0 #define CONSTR 1 }}} you would write: {{{ typedef enum { INVALID_OBJECT = 0, CONSTR = 1 } ClosureType; }}} What you get is easier debugging in gdb, perhaps even better type checking. Unfortunately some files (most vexingly `rts/storage/ClosureTypes.h`) are included in both C and Cmm and Cmm doesn't support this syntax. As far as I can tell all constants in Cmm are defined with preprocessor `#define`s. Implementing enums/constants may seem like an overkill, but I haven't found a good workaround for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14134> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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 16 Aug '17

16 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 16 Aug '17

16 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