- ghc-tickets - Haskell.org

[GHC] #14546: -Woverlapping-patterns warns on wrong patterns for Int
by GHC 03 Jun '18

03 Jun '18

#14546: -Woverlapping-patterns warns on wrong patterns for Int -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Type checker) | 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: -------------------------------------+------------------------------------- GHC-8.0 introduced a new warning on redundant pattern matches in `case` clauses. But there is something strange. {{{ $ cat RedundantCase.hs main :: IO () main = do case 0::Int of 0 -> putStrLn "A" 1 -> putStrLn "B" _ -> putStrLn "C" case 0::Int of 0 -> putStrLn "A" 1 -> putStrLn "B" 2 -> putStrLn "C" case 0::Integer of 0 -> putStrLn "A" 1 -> putStrLn "B" _ -> putStrLn "C" case 0::Integer of 0 -> putStrLn "A" 1 -> putStrLn "B" 2 -> putStrLn "C" case 0::Integer of 1 -> putStrLn "B" 2 -> putStrLn "C" let dummy :: Integer dummy = 0 case dummy of 0 -> putStrLn "A" 1 -> putStrLn "B" _ -> putStrLn "C" case "foo" of "foo" -> putStrLn "A" "bar" -> putStrLn "B" "baz" -> putStrLn "C" if True then putStrLn "X" else putStrLn "Y" }}} {{{ $ ghc-8.2.2 -Wall RedundantCase.hs [1 of 1] Compiling Main ( RedundantCase.hs, RedundantCase.o ) RedundantCase.hs:4:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 0 -> ... | 4 | 0 -> putStrLn "A" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:5:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 1 -> ... | 5 | 1 -> putStrLn "B" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:8:4: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: 0 | 8 | case 0::Int of | ^^^^^^^^^^^^^^... RedundantCase.hs:9:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 0 -> ... | 9 | 0 -> putStrLn "A" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:10:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 1 -> ... | 10 | 1 -> putStrLn "B" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:11:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 2 -> ... | 11 | 2 -> putStrLn "C" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:15:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 1 -> ... | 15 | 1 -> putStrLn "B" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:16:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: _ -> ... | 16 | _ -> putStrLn "C" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:20:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 1 -> ... | 20 | 1 -> putStrLn "B" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:21:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 2 -> ... | 21 | 2 -> putStrLn "C" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:23:4: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: 0 | 23 | case 0::Integer of | ^^^^^^^^^^^^^^^^^^... RedundantCase.hs:24:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 1 -> ... | 24 | 1 -> putStrLn "B" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:25:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 2 -> ... | 25 | 2 -> putStrLn "C" | ^^^^^^^^^^^^^^^^^ RedundantCase.hs:34:4: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: [] (p:_) where p is not one of {'b', 'f'} ['b'] ('b':p:_) where p is not one of {'a'} ... | 34 | case "foo" of | ^^^^^^^^^^^^^... Linking RedundantCase ... }}} In the first case it warns about the wrong patterns, in the second case it warns about all patterns and a non-exhaustive pattern list. In the following three cases using `Integer` the warnings seem to be correct. The next case shows that I can suppress the warning if I hide the constant nature of the case selector a bit. Then a case on a `String` - GHC does not seem to try to detect redundant pattern matches but falls back to a general test on exhaustive pattern lists. Finally, in a constant `case` on `Bool` I can avoid the warning using a plain `if-then-else`. Now I wonder what the purpose of the warning is at all. First I thought that it wants to warn me, that the patterns overlap, i.e. pattern `_` contains the already handled case `0`. This does not seem to be the purpose of the warning - and such overlapping patterns are pretty common, aren't they? Second thought: GHC wants to warn me about redundant patterns in the presence of a constant case selector. But then, it does so with varying degrees of success: For `Integer` it works, but not for `Int` or `String`. Is it really only about constant case selectors? Then, not only some pattern matches are redundant but the whole `case` clause is redundant. Then again, can't we assume that the programmer wrote such a `case` clause by intend? At least, this is how I use a `case` clause with constant selector: as a type-safe way to out-comment alternative implementations. Thus my question: Where is this warning useful? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14546> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9247: Document -XDatatypeContexts in flag reference
by GHC 03 Jun '18

03 Jun '18

#9247: Document -XDatatypeContexts in flag reference ------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It may be a deprecated feature, but it still exists and should be listed. I can do this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9247> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness?
by GHC 03 Jun '18

03 Jun '18

#11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- GHC 7.10.2 reports inaccessible branches as a type error, and I think this is really a bug. First, the implicit thinking seems to be "why would a user want to write inaccessible cases, they'd be crazy!". But that only applies to human-written code. Program generators can have a great deal of trouble avoiding this error, unless they replicate the GHC type checker to predict the problem and prune branches. (That's why we are hitting this error and are stuck.) Second, it seems like this is a problem for type soundness. See the attached program where "step1" typechecks but "step2" does not. And yet, the operational semantics should allow step1 to reduce to step2. Indeed, in the "GADTs meet their match" paper it seems like the intent was to warn for these inaccessible cases, not error. For example, the paper contains the language: "If we warn that a right-hand side of a non-redundant clause is inaccessible," -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11066> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 50

[GHC] #15217: Typo in documentation
by GHC 03 Jun '18

03 Jun '18

#15217: Typo in documentation -------------------------------------+------------------------------------- Reporter: elpinal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In "10.8.5. Overloaded labels" it says "an overloaded label can written with a prefix hash," but I think it should be "an overloaded label can **be** written with a prefix hash." -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15217> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15017: Come up with a better name for `tcExtendTyVarEnv2`
by GHC 03 Jun '18

03 Jun '18

#15017: Come up with a better name for `tcExtendTyVarEnv2` -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | 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: -------------------------------------+------------------------------------- It must be different somehow from `tcExtendTyVarEnv` but without reading the source code, it's hard to tell what the difference is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15017> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14059: COMPLETE sets don't work at all with data family instances
by GHC 03 Jun '18

03 Jun '18

#14059: COMPLETE sets don't work at all with data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, | PatternMatchWarnings | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's some code that uses a pattern synonym for a data family GADT constructor, along with a corresponding `COMPLETE` set: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where data family Sing (a :: k) data instance Sing (z :: Bool) where SFalse :: Sing False STrue :: Sing True pattern STooGoodToBeTrue :: forall (z :: Bool). () => z ~ True => Sing z pattern STooGoodToBeTrue = STrue {-# COMPLETE SFalse, STooGoodToBeTrue #-} wibble :: Sing (z :: Bool) -> Bool wibble STrue = True wobble :: Sing (z :: Bool) -> Bool wobble STooGoodToBeTrue = True }}} However, if you compile this, you might be surprised to find out that GHC only warns about `wibble` being non-exhaustive: {{{ $ ghci Bug.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:23:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘wibble’: Patterns not matched: SFalse | 23 | wibble STrue = True | ^^^^^^^^^^^^^^^^^^^ }}} I believe the use of data families is the culprit here, since a variant of this program which doesn't use data families correctly warns for both `wibble` and `wobble`: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Foo where data SBool (z :: Bool) where SFalse :: SBool False STrue :: SBool True pattern STooGoodToBeTrue :: forall (z :: Bool). () => z ~ True => SBool z pattern STooGoodToBeTrue = STrue {-# COMPLETE SFalse, STooGoodToBeTrue #-} wibble :: SBool z -> Bool wibble STrue = True wobble :: SBool z -> Bool wobble STooGoodToBeTrue = True }}} {{{ $ ghci Foo.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Foo.hs:20:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘wibble’: Patterns not matched: SFalse | 20 | wibble STrue = True | ^^^^^^^^^^^^^^^^^^^ Foo.hs:23:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘wobble’: Patterns not matched: SFalse | 23 | wobble STooGoodToBeTrue = True | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14059> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15214: Redefining (~) yields a baffling error message
by GHC 03 Jun '18

03 Jun '18

#15214: Redefining (~) yields a baffling error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: -------------------------------------+------------------------------------- Running this code: {{{#!hs {-# LANGUAGE TypeOperators #-} module Bug where type (~) = Either }}} Yields a rather strange error: {{{ $ /opt/ghc/8.4.3/bin/ghci Bug2.hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug2.hs, interpreted ) Bug2.hs:4:1: error: Cannot redefine a Name retrieved by a Template Haskell quote: ~ | 4 | type (~) = Either | ^^^^^^^^^^^^^^^^^ }}} Since Template Haskell certainly isn't involved here. The culprit is that `(~)` isn't listed within `isBuiltInOcc_maybe`. Patch incoming. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15214> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13777: Poor error message around CUSKs
by GHC 03 Jun '18

03 Jun '18

#13777: Poor error message around CUSKs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 Keywords: TypeInType, | Operating System: Unknown/Multiple CUSKs | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While typing up comment:7:ticket:13761, I came across a poor error message around CUSKs. {{{ data Proxy (a :: k) = P data S :: forall k. Proxy k -> Type where MkS :: S (P :: Proxy Maybe) }}} produces {{{ You have written a *complete user-suppled kind signature*, but the following variable is undetermined: k0 :: * Perhaps add a kind signature. Inferred kinds of user-written variables: }}} That promised list of the kinds of user-written variables is empty. Either GHC should find something to print (like `k :: k0`, perhaps) or omit the header. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13777> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #14709: Extend the plugin mechanism to access program representation
by GHC 03 Jun '18

03 Jun '18

#14709: Extend the plugin mechanism to access program representation -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: GHC API | 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: https://phabricator.haskell.org/D4342| https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal -------------------------------------+------------------------------------- This would enable development tools to access the GHC representation in the pre-existing build environment. By the inversion of control, the tool developers don't need to decide which Haskell modules have to be processed and with what configuration, because the normal build procedure could be invoked by the user with plugin flags specifying what tools to invoke. The plan is described in more details at [https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal Extended Plugins Proposal] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14709> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #14324: Consider deprecating STM invariant mechanism
by GHC 03 Jun '18

03 Jun '18

#14324: Consider deprecating STM invariant mechanism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- fryguybob and I were recently discussing the STM invariant mechanism. This mechanism is, presumably, intended to expose problems from odd interleavings of transactions. However, fryguybob pointed out that the implementation currently takes so many locks that it very likely prevents these odd interleavings from occurring. In addition, * the implementation doesn't handle nested STM invariants correctly (#7930) * the locking behavior of the implementation was, until very recently, utterly wrong (#14310) * the feature introduces quite a bit of complexity in the RTS * the interface has essentially no users, as evidenced by a Hackage search and the fact that #14310 went unnoticed for years All of this raises the question: Is the STM invariants feature really where we want to spend our complexity budget? Perhaps it is time for this feature to quietly pass (after an appropriate deprecation period, of course). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14324> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10