August 2018 - ghc-tickets

[GHC] #11409: Cannot instantiate literals using TypeApplications
by GHC 22 Aug '18

22 Aug '18

#11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- {{{ GHCi, version 8.0.1.20160110: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeApplications -fprint-explicit-foralls Prelude> :t 42 42 :: forall {a}. Num a => a Prelude> 42 @Int <interactive>:3:1: error: • Cannot not apply expression of type ‘a0’ to a visible type argument ‘Int’ • In the expression: 42 @Int In an equation for ‘it’: it = 42 @Int }}} (Also, "cannot not" looks like a typo.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11409> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 29

Re: [GHC] #7674: Separate StablePtr table from StableName table.
by GHC 22 Aug '18

22 Aug '18

#7674: Separate StablePtr table from StableName table. -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.2 Resolution: fixed | Keywords: rts | stable_ptr stable_name performance Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15555 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #15555 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7674#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6077: Respect XDG_CONFIG_HOME
by GHC 22 Aug '18

22 Aug '18

#6077: Respect XDG_CONFIG_HOME -------------------------------------+------------------------------------- Reporter: So8res | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: None | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 5966 | Blocking: Related Tickets: #15540 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by potato44): * related: 15540 => #15540 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6077#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6077: Respect XDG_CONFIG_HOME
by GHC 22 Aug '18

22 Aug '18

#6077: Respect XDG_CONFIG_HOME -------------------------------------+------------------------------------- Reporter: So8res | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: None | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 5966 | Blocking: Related Tickets: 15540 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by potato44): * related: => 15540 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6077#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15554: COMPLETE pragmas make overlapping-patterns warnings behave oddly
by GHC 22 Aug '18

22 Aug '18

#15554: COMPLETE pragmas make overlapping-patterns warnings behave oddly -------------------------------------+------------------------------------- Reporter: staffehn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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 can’t really quantify what’s wrong and what’s intended here, here’s a test file comparing different contrasting examples of similar functions which generate no or strange warnings in the cases that use a datatype with COMPLETE pragmas on pattern synonyms. {{{#!hs {- 1 -} {-# LANGUAGE PatternSynonyms, ViewPatterns #-} {- 2 -} {- 3 -} module M where {- 4 -} {- 5 -} data T = A | B | C {- 6 -} {- 7 -} isBC :: T -> Bool {- 8 -} isBC A = False {- 9 -} isBC B = True {- 10 -} isBC C = True {- 11 -} {- 12 -} pattern BC :: T {- 13 -} pattern BC <- (isBC -> True) {- 14 -} {-# COMPLETE A, BC #-} {- 15 -} {- 16 -} g1 :: T -> Int {- 17 -} g1 A = 1 {- 18 -} g1 BC = 2 {- 19 -} g1 _ = 3 {- 20 -} {- 21 -} -- M.hs:18:1: warning: [-Woverlapping-patterns] {- 22 -} -- Pattern match is redundant {- 23 -} -- In an equation for `g1': g1 BC = ... {- 24 -} -- | {- 25 -} -- 18 | {- 18 -} g1 BC = 2 {- 26 -} -- | ^^^^^^^^^ {- 27 -} {- 28 -} g2 :: T -> Int {- 29 -} g2 BC = 2 {- 30 -} g2 A = 1 {- 31 -} g2 _ = 3 {- 32 -} {- 33 -} -- g2: no warnings {- 34 -} {- 35 -} g3 :: T -> Int {- 36 -} g3 BC = 2 {- 37 -} g3 _ = 1 {- 38 -} g3 A = 3 {- 39 -} g3 A = 4 {- 40 -} g3 B = 4 {- 41 -} g3 B = 4 {- 42 -} g3 C = 4 {- 43 -} g3 C = 4 {- 44 -} g3 _ = 4 {- 45 -} g3 _ = 4 {- 46 -} {- 47 -} -- g3: no warnings {- 48 -} {- 49 -} data T' = A' | B' | C' {- 50 -} {- 51 -} isBC' :: T' -> Bool {- 52 -} isBC' A' = False {- 53 -} isBC' B' = True {- 54 -} isBC' C' = True {- 55 -} {- 56 -} pattern BC' :: T' {- 57 -} pattern BC' <- (isBC' -> True) {- 58 -} -- no COMPLETE pragma {- 59 -} {- 60 -} g3' :: T' -> Int {- 61 -} g3' BC' = 2 {- 62 -} g3' _ = 1 {- 63 -} g3' A' = 3 {- 64 -} g3' A' = 4 {- 65 -} g3' B' = 4 {- 66 -} g3' B' = 4 {- 67 -} g3' C' = 4 {- 68 -} g3' C' = 4 {- 69 -} g3' _ = 4 {- 70 -} g3' _ = 4 {- 71 -} {- 72 -} -- M.hs:63:1: warning: [-Woverlapping-patterns] {- 73 -} -- Pattern match is redundant {- 74 -} -- In an equation for g3': g3' A' = ... {- 75 -} -- | {- 76 -} -- 63 | {- 63 -} g3' A' = 3 {- 77 -} -- | ^^^^^^^^^^ {- 78 -} -- {- 79 -} -- M.hs:64:1: warning: [-Woverlapping-patterns] {- 80 -} -- Pattern match is redundant {- 81 -} -- In an equation for g3': g3' A' = ... {- 82 -} -- | {- 83 -} -- 64 | {- 64 -} g3' A' = 4 {- 84 -} -- | ^^^^^^^^^^ {- 85 -} -- {- 86 -} -- M.hs:65:1: warning: [-Woverlapping-patterns] {- 87 -} -- Pattern match is redundant {- 88 -} -- In an equation for g3': g3' B' = ... {- 89 -} -- | {- 90 -} -- 65 | {- 65 -} g3' B' = 4 {- 91 -} -- | ^^^^^^^^^^ {- 92 -} -- {- 93 -} -- M.hs:66:1: warning: [-Woverlapping-patterns] {- 94 -} -- Pattern match is redundant {- 95 -} -- In an equation for g3': g3' B' = ... {- 96 -} -- | {- 97 -} -- 66 | {- 66 -} g3' B' = 4 {- 98 -} -- | ^^^^^^^^^^ {- 99 -} -- {- 100 -} -- M.hs:67:1: warning: [-Woverlapping-patterns] {- 101 -} -- Pattern match is redundant {- 102 -} -- In an equation for g3': g3' C' = ... {- 103 -} -- | {- 104 -} -- 67 | {- 67 -} g3' C' = 4 {- 105 -} -- | ^^^^^^^^^^ {- 106 -} -- {- 107 -} -- M.hs:68:1: warning: [-Woverlapping-patterns] {- 108 -} -- Pattern match is redundant {- 109 -} -- In an equation for g3': g3' C' = ... {- 110 -} -- | {- 111 -} -- 68 | {- 68 -} g3' C' = 4 {- 112 -} -- | ^^^^^^^^^^ {- 113 -} -- {- 114 -} -- M.hs:69:1: warning: [-Woverlapping-patterns] {- 115 -} -- Pattern match is redundant {- 116 -} -- In an equation for g3': g3' _ = ... {- 117 -} -- | {- 118 -} -- 69 | {- 69 -} g3' _ = 4 {- 119 -} -- | ^^^^^^^^^ {- 120 -} -- {- 121 -} -- M.hs:70:1: warning: [-Woverlapping-patterns] {- 122 -} -- Pattern match is redundant {- 123 -} -- In an equation for g3': g3' _ = ... {- 124 -} -- | {- 125 -} -- 70 | {- 70 -} g3' _ = 4 {- 126 -} -- | ^^^^^^^^^ {- 127 -} {- 128 -} {- 129 -} data S = X {- 130 -} {- 131 -} pattern Y :: S {- 132 -} pattern Y = X {- 133 -} {-# COMPLETE Y #-} {- 134 -} {- 135 -} f1 :: S -> Int {- 136 -} f1 Y = 1 {- 137 -} f1 _ = 2 {- 138 -} {- 139 -} -- f1: no warnings {- 140 -} {- 141 -} f2 :: S -> Int {- 142 -} f2 X = 1 {- 143 -} f2 _ = 2 {- 144 -} {- 145 -} -- M.hs:143:1: warning: [-Woverlapping-patterns] {- 146 -} -- Pattern match is redundant {- 147 -} -- In an equation for `f2': f2 _ = ... {- 148 -} -- | {- 149 -} -- 143 | {- 143 -} f2 _ = 2 {- 150 -} -- | ^^^^^^^^ {- 151 -} {- 152 -} f3 :: S -> Int {- 153 -} f3 Y = 0 {- 154 -} f3 X = 1 {- 155 -} f3 _ = 2 {- 156 -} {- 157 -} -- f3: no warnings {- 158 -} {- 159 -} data S' = X' {- 160 -} {- 161 -} pattern Y' :: S' {- 162 -} pattern Y' = X' {- 163 -} -- no COMPLETE pragma {- 164 -} {- 165 -} f3' :: S' -> Int {- 166 -} f3' Y' = 1 {- 167 -} f3' X' = 0 {- 168 -} f3' _ = 2 {- 169 -} {- 170 -} -- M.hs:168:1: warning: [-Woverlapping-patterns] {- 171 -} -- Pattern match is redundant {- 172 -} -- In an equation for f3': f3' _ = ... {- 173 -} -- | {- 174 -} -- 168 | {- 168 -} f3' _ = 2 {- 175 -} -- | ^^^^^^^^^ }}} In particular: the warning for line 18 should probably be a warning for line 19, and there should be a similar warning for line 31. `g3` extends `g2` in a ridiculous way still without generating any warnings. `g3'` demonstrates the warnings one should expect. The `f` functions are perhaps a bit redundant, but I wanted to include a smaller datatype. I’m not sure if this is easily fixable, since I’m having doubts, that COMPLETE pragmas give enough information for generating good overlapping- patterns warnings. I didn’t think this matter through in detail, but, well, maybe it’s not that important to have this all that sophisticated anyways, since for example guards won’t give overlapping-patterns warnings either. But at least (IMO) it’d be nice to keep the warnings about the normal constructor’s patterns even when they’re mixed with pattern synonyms that have a COMPLETE pragma. Even further, I would always expect overlapping-patterns warnings when a pattern is simply duplicated and probably always if any additional pattern follows a complete listing of everything in a COMPLETE group. And there’s probably lots of cases one could consider naturally suggesting a warning; maybe someone can find a good principle/algorithm to use here. Going further, to prevent COMPLETE pragma setting that always give an overlapping-patterns or incomplete-patterns warnings, one could even consider warning directly at a COMPLETE pragma when it’s a strict subset of an existing COMPLETE group. By the way, my actual goal while finding this bug was to describe another (maybe) bug, which is that the incomplete-patterns warnings can suggest missing pattern synonyms that are not even in scope, which seems not very neat in some cases. In case someone really wants to rework all these warnings, I can make a separate ticket or give details on such a non-neat case that here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15554> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings
by GHC 22 Aug '18

22 Aug '18

#13363: Wildcarn patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this program: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where data Boolean = F | T deriving Eq pattern TooGoodToBeTrue :: Boolean pattern TooGoodToBeTrue <- ((== T) -> True) where TooGoodToBeTrue = T {-# COMPLETE F, TooGoodToBeTrue #-} catchAll :: Boolean -> Int catchAll F = 0 catchAll TooGoodToBeTrue = 1 }}} This compiles with no warnings with `-Wall`. But if you tweak `catchAll` to add a catch-all case at the end: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where data Boolean = F | T deriving Eq pattern TooGoodToBeTrue :: Boolean pattern TooGoodToBeTrue <- ((== T) -> True) where TooGoodToBeTrue = T {-# COMPLETE F, TooGoodToBeTrue #-} catchAll :: Boolean -> Int catchAll F = 0 catchAll TooGoodToBeTrue = 1 catchAll _ = error "impossible" }}} Then if you compile it with `-Wall`, you'll get a very misleading warning: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs -Wall GHCi, version 8.1.20170228: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:17:1: warning: [-Woverlapping-patterns] Pattern match is redundant In an equation for ‘catchAll’: catchAll TooGoodToBeTrue = ... | 17 | catchAll TooGoodToBeTrue = 1 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} I would have expected the warning to be on the `catchAll _ = error "impossible"` case! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13363> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10869: Option to dump preprocessed source
by GHC 21 Aug '18

21 Aug '18

#10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Driver | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- It would be awesome if GHC had an option `-ddump-preprocessed` that dumps the source code for each module after preprocessing. I am not sure what the current definition of "preprocessing" is but I mean the output of at least the following tools: happy, alex, c2hs, hsc2hs and cpp. Additionally even if a module was not subject to any preprocessing it should be dumped anyway. Use case: I want to parse module files from packages from hackage with `haskell-src-exts` but find it prohibitively difficult to get the preprocessing right. The idea is that after `cabal install` with ghc options `-ddump-preprocessed -ddump-to-file -dumpdir real_modules` you get a complete working set of haskell modules that can be parsed directly without any preprocessing in folder `real_modules`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10869> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #15189: Avoid word "transformer" in the documentation of ST
by GHC 21 Aug '18

21 Aug '18

#15189: Avoid word "transformer" in the documentation of ST -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.2.2 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'm unhappy about the current wording in the documentation of the ST module in base. Let me explain why. Some time ago, as a novice, I struggled to get the difference between three monad-related concepts: 1. The State monad. 2. The StateT monad transformer. 3. The ST monad. Current [http://hackage.haskell.org/package/base-4.11.1.0/docs/Control- Monad-ST.html documentation for ST] says that "ST" stands for state transformer (see everywhere except for the introduction paragraph). While this follows original 1994 paper "Lazy Functional State Threads", I find this confusing after the adoption of term "(monad) transformer" due to 1995 paper "Functional Programming with Overloading and Higher-Order Polymorphism". Note that ST paper predates MT one. At the same time, the 1994 paper itself (in the title) and some current tutorials, [https://wiki.haskell.org/Monad/ST like the one at HaskelWiki], use the word "thread" to describe what's going on, avoiding discussion of spelling of ST. As the bottom line, I think, it would be helpful, especially for a novice, to avoid the word "transformer" in the documentation of ST module. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15261: Show -with-rtsopts options in runtime's --info
by GHC 21 Aug '18

21 Aug '18

#15261: Show -with-rtsopts options in runtime's --info -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- As far as I know currently we don't have a way to show `-with-rtsopts` options provided when compiling an executable. It'd be useful if `--info` showed this. Some use cases: - When you have multiple binaries of the same program you can see how each one is compiled. Useful when debugging. - Sometimes we instruct users saying "compile with this and run with that". This steps becomes easier with `-with-rtsopts` because with that the user doesn't have to pass runtime parameters. But currently we don't have an easy way check if the users did it right. If `+RTS --info` showed this information we could say "look at the info, you should see this and that". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15261> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15426: `elemIndex` and `findIndex` still can't fuse
by GHC 21 Aug '18

21 Aug '18

#15426: `elemIndex` and `findIndex` still can't fuse -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: | Version: 8.4.3 libraries/base | 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: -------------------------------------+------------------------------------- Ticket #14387 introduced a change to the implementation of `listToMaybe` to allow: {{{#!hs findIndex p = listToMaybe . findIndices p }}} to fuse. However, to take advantage of this, it looks like we also need `findIndex` (and `elemIndex`) to be marked inlinable (or some similar step). As a concrete example, the module: {{{#!hs module Foo where import Data.List (findIndex) foo :: Maybe Int foo = findIndex (==999999) [1..1000000] }}} compiled with GHC 8.4.3 using `-O2` produces the following unfused core: {{{#!hs foo_go = \ ds1_a2ws eta_a2wt -> case ds1_a2ws of { [] -> Nothing; : y_a2wx ys_a2wy -> case eqInteger# y_a2wx ds_r2we of { __DEFAULT -> foo_go ys_a2wy (+# eta_a2wt 1#); 1# -> Just (I# eta_a2wt) } } foo = foo_go (enumDeltaToInteger1 foo2 foo1) 0# }}} but if the definition of `findIndex` from `Data.OldList` is copied into the module or imported from another module with an `INLINABLE` pragma, then it fuses fine: {{{#!hs foo_go = \ x_a2Du eta_B1 -> case gtInteger# x_a2Du lim_r2Ey of { __DEFAULT -> case eqInteger# x_a2Du ds_r2Cv of { __DEFAULT -> foo_go (plusInteger x_a2Du foo1) (+# eta_B1 1#); 1# -> Just (I# eta_B1) }; 1# -> Nothing } foo = foo_go foo1 0# }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15426> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11