June 2017 - ghc-tickets

[GHC] #12389: Limit duplicate export warnings for datatypes
by GHC 20 Mar '18

20 Mar '18

#12389: Limit duplicate export warnings for datatypes -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #11959 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `containers` sometimes exports data constructors/patterns conditionally (depending on GHC version and whether `TESTING` is defined). Presently, to avoid a duplicate export warning, it's necessary to write a separate export line for each combination of exported constructors, which is horrible: {{{#!hs module Foo ( #ifdef TESTING #ifdef USE_PATTERN_SYNONYMS Foo (Foo, Pat1, Pat2) #else Foo (Foo) #endif #elif USE_PATTERN_SYNONYMS Foo (Pat1, Pat2) #else Foo #endif }}} or to break up the lines with CPP, which is so horrible I can't even bring myself to write it. I'd much rather be able to write {{{#!hs module Foo ( Foo #ifdef TESTING ,Foo(Foo) #endif #ifdef USE_PATTERN_SYNONYMS ,Foo(Pat1, Pat2) #endif ) }}} The trouble here is that GHC warns about duplicate export of the type `Foo`. I think there's a pretty simple partial solution: only warn about a type export that is *completely* redundant, adding neither type constructor nor pattern. And offer a way to turn off the redundant export warning entirely for types and classes without turning it off for bindings. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12389> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #13386: Poor compiler performance with type families
by GHC 20 Mar '18

20 Mar '18

#13386: Poor compiler performance with type families -------------------------------------+------------------------------------- Reporter: adamgundry | 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 | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider: {{{#!hs {-# LANGUAGE DataKinds, TypeApplications, TypeFamilies, TypeOperators, UndecidableInstances #-} {-# OPTIONS_GHC -freduction-depth=0 #-} module TypeFamilyPerf where import GHC.TypeLits type DivisibleBy x y = Help x y 0 (CmpNat x 0) type family Help x y z b where Help x y z EQ = True Help x y z LT = False Help x y z GT = Help x y (z+y) (CmpNat x z) foo :: DivisibleBy y 3 ~ True => proxy y -> () foo _ = () type N = 1002 k = foo @N undefined }}} On my machine `ghc-8.0.2 -O0` takes 4-5s to compile this module, with the time increasing as `N` increases (but note that it must be a multiple of 3, otherwise typechecking fails quickly). The problem seems to be that desugaring creates an enormous number of coercions in the representation of `k`. Perhaps this isn't terribly surprising, but I think we can do better. It should be possible to represent a proof of `DivisibleBy 1002 3 ~ True` compactly: the only information required should be the LHS and the number of reduction steps to take (and perhaps caching the RHS might be worthwhile). {{{ [1 of 1] Compiling TypeFamilyPerf ( TypeFamilyPerf.hs, TypeFamilyPerf.o ) *** Parser [TypeFamilyPerf]: !!! Parser [TypeFamilyPerf]: finished in 0.50 milliseconds, allocated 0.655 megabytes *** Renamer/typechecker [TypeFamilyPerf]: !!! Renamer/typechecker [TypeFamilyPerf]: finished in 91.70 milliseconds, allocated 58.617 megabytes *** Desugar [TypeFamilyPerf]: Result size of Desugar (after optimization) = {terms: 44, types: 70, coercions: 6,058} !!! Desugar [TypeFamilyPerf]: finished in 3781.83 milliseconds, allocated 8775.375 megabytes *** Simplifier [TypeFamilyPerf]: Result size of Simplifier iteration=1 = {terms: 27, types: 62, coercions: 6,060} Result size of Simplifier = {terms: 27, types: 62, coercions: 6,053} !!! Simplifier [TypeFamilyPerf]: finished in 42.93 milliseconds, allocated 68.321 megabytes *** CoreTidy [TypeFamilyPerf]: Result size of Tidy Core = {terms: 27, types: 62, coercions: 6,053} !!! CoreTidy [TypeFamilyPerf]: finished in 0.52 milliseconds, allocated 0.766 megabytes Created temporary directory: /tmp/ghc5526_0 *** CorePrep [TypeFamilyPerf]: Result size of CorePrep = {terms: 32, types: 74, coercions: 6,053} !!! CorePrep [TypeFamilyPerf]: finished in 0.37 milliseconds, allocated 0.160 megabytes *** Stg2Stg: *** CodeGen [TypeFamilyPerf]: !!! CodeGen [TypeFamilyPerf]: finished in 0.00 milliseconds, allocated 1.310 megabytes }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13386> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13776: -ddump-splices produces unnecessarily qualified names for tuple and list types
by GHC 20 Mar '18

20 Mar '18

#13776: -ddump-splices produces unnecessarily qualified names for tuple and list types -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you compile this: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Language.Haskell.TH f :: $(conT ''(,) `appT` conT ''Int `appT` conT ''Int) f = (1,2) g :: $(conT ''[] `appT` conT ''Int) g = [] }}} You'll get some unsavory output: {{{ Bug.hs:10:8-34: Splicing type conT ''[] `appT` conT ''Int ======> GHC.Types.[] Int Bug.hs:7:8-53: Splicing type conT ''(,) `appT` conT ''Int `appT` conT ''Int ======> GHC.Tuple.(,) Int Int }}} It's unsavory because if you actually try to use the spliced output in Haskell code: {{{#!hs module Bug2 where f :: GHC.Tuple.(,) Int Int f = (1,2) g :: GHC.Types.[] Int g = [] }}} Then it won't parse. Expressions have the same problem: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug3 where import Language.Haskell.TH f :: (Int, Int) f = $(conE '(,) `appE` litE (integerL 1) `appE` litE (integerL 1)) g :: [Int] g = $(conE '[]) }}} {{{ Bug3.hs:8:7-65: Splicing expression conE '(,) `appE` litE (integerL 1) `appE` litE (integerL 1) ======> (GHC.Tuple.(,) 1) 1 Bug3.hs:11:7-14: Splicing expression conE '[] ======> GHC.Types.[] }}} And patterns: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug4 where import Language.Haskell.TH f :: (Int, Int) -> () f $(conP '(,) [litP (integerL 1), litP (integerL 1)]) = () g :: [Int] -> () g $(conP '[] []) = () }}} {{{ Bug4.hs:8:5-52: Splicing pattern conP '(,) [litP (integerL 1), litP (integerL 1)] ======> GHC.Tuple.(,) 1 1 Bug4.hs:11:5-15: Splicing pattern conP '[] [] ======> GHC.Types.[] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13776> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10774: Use `Natural` rather than `Integer` in `GHC.TypeLits`
by GHC 19 Mar '18

19 Mar '18

#10774: Use `Natural` rather than `Integer` in `GHC.TypeLits` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: | Version: 7.10.2 libraries/base | Keywords: TypeLits | Operating System: Unknown/Multiple Natural | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When the numeric type-literals were implement via `GHC.TypeLits` there was no `Natural` type in `base` yet. But since GHC 7.10 we finally have `Natural` available in base! Specifically, the following 3 type-signatures in `GHC.TypeLits` cpmtaom `Integer` that ought rather be `Natural`s: {{{#!hs someNatVal :: Integer -> Maybe SomeNat natVal :: forall n proxy. KnownNat n => proxy n -> Integer natVal' :: forall n. KnownNat n => Proxy# n -> Integer }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10774> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9671: Allow expressions in patterns
by GHC 17 Mar '18

17 Mar '18

#9671: Allow expressions in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: Keywords: patterns, pattern | Operating System: synonyms | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I've outlined a proposal for extending pattern synonyms to depend on terms (PatternFamilies), the name is less than ideal but I'll keep the page under that name for now. The proposal's introduction has been rewritten. The simplest use case are patterns that matches only when a set contains an element (`IsMember`) or when a set does not contain an element (`NotMember`): [[Image(wiki:PatternFamilies:member.png)]] {{{#!hs hasKeys :: Set Item -> IO () hasKeys (IsMember "keys") = leaveHouse hasKeys (NotMember "keys") = findKeys >> leaveHouse }}} or a pattern that matches a map if the key exists: [[Image(wiki:PatternFamilies:lookup.png)]] used like this: {{{#!hs age :: Map Person Age -> String age (Lookup "Alice" 60) = "Alice is 60 years old!" age (Lookup "Alice" age) = "Alice is " ++ show age ++ "." age (Lookup "Bob" _) = "No info on Alice but we know how old Bob is." age _ = "..." }}} Further details and examples can be found here: PatternFamilies, I discussed it with several people ICFP 2014. This would not require a new extension but would extend PatternSynonyms. This feature can be quite useful, especially when working with deeply nested structures (ASTs, JSON, XML, ...). If people are fine with it I will implement it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #11312: GHC inlining primitive string literals can affect program output
by GHC 14 Mar '18

14 Mar '18

#11312: GHC inlining primitive string literals can affect program output -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #11292 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First noted in #11292, this program, when compiled with `-O1` or higher: {{{#!hs {-# LANGUAGE MagicHash #-} module Main (main) where import GHC.Exts (Addr#, isTrue#) import GHC.Prim (eqAddr#) data A = A { runA :: Addr# } a :: A a = A "a"# main :: IO () main = print (isTrue# (eqAddr# (runA a) (runA a))) }}} will result in the following after inlining: {{{ Main.main2 = case GHC.Prim.tagToEnum# @ GHC.Types.Bool (GHC.Prim.eqAddr# "a"# "a"#) of _ [Occ=Dead] { GHC.Types.False -> GHC.Show.shows26; GHC.Types.True -> GHC.Show.shows24 } }}} As a result, there are two of the same string constant with different addresses, which causes `eqAddr#` to return `False`. If compiled without optimizations, `"a"#` is not inlined, and as a result, `eqAddr#` returns `True`. Two questions: 1. Is this okay semantics-wise? Or is this a necessary risk when working with primitive string literals, and should programmers judiciously use `{-# NOINLINE #-}` with them? 2. Is this okay from a code duplication standpoint? As Reid Barton noted in #11292, `"a"#` is duplicated due to inlining. In this example, not much is duplicated, but if it were a longer string constant, that could result in a noticeable increase in the object file size. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11312> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8542: Suggest NegativeLiterals
by GHC 14 Mar '18

14 Mar '18

#8542: Suggest NegativeLiterals ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If we write -128 :: Int8, we get a useful warning (#7895), but it would be even better to suggest NegativeLiterals. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8542> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13257: out-of-range warnings for negative literals, without -XNegativeLiterals
by GHC 13 Mar '18

13 Mar '18

#13257: out-of-range warnings for negative literals, without -XNegativeLiterals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- By default (without `NegativeLiterals`) a negated literal `-1` is desugared as `negate (fromInteger 1)`. Hence the existing out-of-range literal warning doesn't trigger for `-1 :: Word`. But we could also recognize the pattern `negate (fromInteger lit)`, and give a warning when `-lit` is out-of-range (for `Word`, this is whenever `lit` is positive). Actually this could apply to signed integer types too: if we recognized `negate (fromInteger lit)` in preference to `fromInteger lit`, we could correctly not warn about `-128 :: Int8`, even when `NegativeLiterals` is not enabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13257> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13366: addCStub doesn't allow control over compiler flags or source file file
by GHC 13 Mar '18

13 Mar '18

#13366: addCStub doesn't allow control over compiler flags or source file file -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- Currently if you pass a C source file on the GHC command line you can control whether the compiler treats it as C or C++ via the it's extension: GCC will treat a file ending in `.c` as C, whereas `.cpp` is treated as C++. However, we currently have no means of controlling what language a stub added with in Template Haskell with `addCStub` will be treated as. Consequently it is currently impossible to compile a C++ source file with `addCStub` without using `-optc`. Moreover, you can't have mixed C/C++ stubs at all. It really seems like this interface should be amended to fix this before we release it in 8.2. Perhaps `addCStub` should accept both the source and a set of compiler flags which will be added to the usual flags (allowing one to pass `-x c++` to the compiler when compiling C++ files)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13366> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #13543: Improve demand analysis for join points
by GHC 13 Mar '18

13 Mar '18

#13543: Improve demand analysis for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) 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: -------------------------------------+------------------------------------- Consider {{{ g :: (Int,Int) -> Int g (p,q) = p+q f :: Int -> Int -> Int f x p = g (join j y = (p,y) in case x of True -> j 3 False -> j 4) }}} If `j` was a vanilla function definition, we'd analyse its body with `evalDmd`, and think that it was lazy in `p`. But for a join point we can do better. We know that `j`'s body (if evaluated at all) will be evaluated with the demand that consumes the entire join-binding, in this case the argument demand from `g`. Whizzo! `g` evaluates both components of its arugment pair, so j is strict in `p`. So, when analysing a join point, we can analyse its body with the demand from the entire join-binding. Another win for join points! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13543> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7