GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-14T09:09:32Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24508Do not emit `-Winaccessible-code` warnings when the pattern-match checker wou...2024-03-14T09:09:32ZSebastian GrafDo not emit `-Winaccessible-code` warnings when the pattern-match checker would warn as wellhttps://discourse.haskell.org/t/inaccessible-vs-redundant-warnings-in-gadt-pattern-matching/8952 had one more user confused by the apparent redundancy of `-Winaccessible-code` warnings with those of the pattern-match checker.
In https:/...https://discourse.haskell.org/t/inaccessible-vs-redundant-warnings-in-gadt-pattern-matching/8952 had one more user confused by the apparent redundancy of `-Winaccessible-code` warnings with those of the pattern-match checker.
In https://gitlab.haskell.org/ghc/ghc/-/issues/19428 I proposed to deprecate `-Winaccessible-code` for this reason, but @RyanGlScott correctly pointed out that there are inaccessible code warnings that have no equivalent in the pattern-match checker.
So in this ticket, I instead propose not to generate `-Winaccessible-code` warnings inside patterns.https://gitlab.haskell.org/ghc/ghc/-/issues/24234Warning for incomplete irrefutable patterns is confusing2023-12-21T21:18:00ZDanil BerestovWarning for incomplete irrefutable patterns is confusing## Summary
Pattern exhaustive check is broken for lazy/irrefutable patterns
## Steps to reproduce
https://play.haskell.org/saved/o5fg9jiD
try to compile this code with version 9.2+
```haskell
{-# OPTIONS_GHC -Wall #-}
main :: IO ()
ma...## Summary
Pattern exhaustive check is broken for lazy/irrefutable patterns
## Steps to reproduce
https://play.haskell.org/saved/o5fg9jiD
try to compile this code with version 9.2+
```haskell
{-# OPTIONS_GHC -Wall #-}
main :: IO ()
main = foo undefined undefined undefined
foo :: [Either a1 b] -> [a2] -> [a3] -> a4
foo [] _ _ = undefined
foo (Left _ : _) ~(_a:_as) _ = undefined
foo (Right _ : _) _ ~(_a:_as) = undefined
foo _ _ _ = undefined
```
It produces three warnings. Patterns are non-exhaustive and redundant at the same time:
```haskell
Main.hs:7:1: warning: [-Wincomplete-uni-patterns]
Pattern match(es) are non-exhaustive
In a pattern binding: Patterns of type ‘[a3]’ not matched: []
|
7 | foo [] _ _ = undefined
| ^^^^^^^^^^^^^^^^^^^^^^...
Main.hs:7:1: warning: [-Wincomplete-uni-patterns]
Pattern match(es) are non-exhaustive
In a pattern binding: Patterns of type ‘[a2]’ not matched: []
|
7 | foo [] _ _ = undefined
| ^^^^^^^^^^^^^^^^^^^^^^...
Main.hs:10:1: warning: [-Woverlapping-patterns]
Pattern match is redundant
In an equation for ‘foo’: foo _ _ _ = ...
|
10 | foo _ _ _ = undefined
| ^^^^^^^^^^^^^^^^^^^^^
```
## Expected behavior
Expected only one warning about redundant pattern:
```haskell
Main.hs:10:1: warning: [-Woverlapping-patterns]
Pattern match is redundant
In an equation for ‘foo’: foo _ _ _ = ...
|
10 | foo _ _ _ = undefined
| ^^^^^^^^^^^^^^^^^^^^^
```
## Environment
* GHC version used: 9.2, 9.4, 9.6, 9.8https://gitlab.haskell.org/ghc/ghc/-/issues/24048Allow disjunctions in COMPLETE pragmas2023-10-03T14:18:19ZTeo CamarasuAllow disjunctions in COMPLETE pragmas<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appr...<!--
READ THIS FIRST: If the feature you are proposing changes the language that GHC accepts
or adds any warnings to `-Wall`, it should be written as a [GHC Proposal](https://github.com/ghc-proposals/ghc-proposals/).
Other features, appropriate for a GitLab feature request, include GHC API/plugin
innovations, new low-impact compiler flags, or other similar additions to GHC.
-->
## Motivation
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11200#note_525994 lays out a limitation of COMPLETE pragmas.
One might want to have a data type with N sets of M interchangeable patterns, but currently this would require `N * M` COMPLETE pragmas.
I was surprised by this since `MINIMAL` pragmas for typeclasses allow having disjunctions, eg, we can say:
```haskell
{-# MINIMAL foo, (bar | baz) #-}
```
In my mind these two constructs are analogous so I was surprised that they differed in this way.
## Proposal
`COMPLETE` pragmas should support both conjunction and disjunction (with `,` and `|` respectively) just like `MINIMAL` pragmas.
I think this would require a GHC proposal. I don't currently have the time to write one up but I hope I will in the future. But I thought I'd make a ticket in case someone else wanted to and if not so I don't forget about ithttps://gitlab.haskell.org/ghc/ghc/-/issues/23915GHC 9.6+: -Woverlapping-patterns triggers in compiled code, but not in GHCi2023-09-07T10:54:57ZRyan ScottGHC 9.6+: -Woverlapping-patterns triggers in compiled code, but not in GHCiConsider this somewhat silly example (that is heavily minimized from a much larger piece of code in the wild):
```hs
{-# OPTIONS_GHC -Woverlapping-patterns #-}
module Bug where
import Data.Traversable
f :: () -> ()
f _ | (_, []) <- ma...Consider this somewhat silly example (that is heavily minimized from a much larger piece of code in the wild):
```hs
{-# OPTIONS_GHC -Woverlapping-patterns #-}
module Bug where
import Data.Traversable
f :: () -> ()
f _ | (_, []) <- mapAccumL (\s a -> (s, a)) () []
= ()
| (_, _:_) <- mapAccumL (\s a -> (s, a)) () []
= ()
f _ = ()
```
The `f _ = ()` equation is redundant, as the two `mapAccumL` guards above it cover all possible cases. If you compile this program directly with GHC 9.6.2, it will warn you about this as expected:
```
$ ghc-9.6.2 Bug.hs -fforce-recomp
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:11:1: warning: [GHC-53633] [-Woverlapping-patterns]
Pattern match is redundant
In an equation for ‘f’: f _ = ...
|
11 | f _ = ()
| ^^^^^^^
```
On the other hand, it will _not_ warn you if you load the code into GHCi:
```
$ ghci-9.6 Bug.hs
GHCi, version 9.6.2: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/ryanglscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Ok, one module loaded.
```
This feels inconsistent.
Note that on older version of GHC (e.g., 9.4), no `-Woverlapping-patterns` are given at all, regardless of whether you use GHC or GHCi.https://gitlab.haskell.org/ghc/ghc/-/issues/23581Pattern match checking across monadic bind2023-06-29T15:49:28Zsheafsam.derbyshire@gmail.comPattern match checking across monadic bindAs noted by @barci2, it would be nice if the following kind of programs didn't cause any pattern match warnings to be emitted:
```haskell
data T = T1 { fld :: Int } | T2
foo :: [T]
foo = do { T1 {} <- [a,b]; v <- [ b { fld = 4 }, a { f...As noted by @barci2, it would be nice if the following kind of programs didn't cause any pattern match warnings to be emitted:
```haskell
data T = T1 { fld :: Int } | T2
foo :: [T]
foo = do { T1 {} <- [a,b]; v <- [ b { fld = 4 }, a { fld = 3 } ]; return v }
bar :: Maybe T
bar = do { T1 {} <- Just c; return $ c { fld = 5 } }
```
In these examples, `a`, `b`, and `c` should all be considered to be scrutinees from the point of view of the function `matchSinglePatVar`. Doing so would then mean that the call to `addCoreScrutTmCs` inside that function will propagate the fact that `a`, `b`, and `c` are all of the form `T1 _`, which will allow GHC to see that the record updates are not partial.
To do this, in the compiler, we would need some kind of function:
```haskell
bindStmtRhsScruts :: XBindStmtTc -> CoreExpr -> [CoreExpr]
```
which would be able to extract out scrutinees from an expression, e.g.
```haskell
bindStmtRhsScruts ( BindStmt for List ) ( Core of explicit list "[a,b]" ) = [a,b]
bindStmtRhsScruts ( BindStmt for Maybe ) ( Core of "Just c" ) = [c]
```
I'm not sure how we would implement this function in general, without implementing ad-hoc logic for known container types such as lists.
@sgraf812, do you have any thoughts?https://gitlab.haskell.org/ghc/ghc/-/issues/23241Incorrect inaccessibility warnings with impredicative types and GADTs2023-04-25T11:01:51ZJaro ReindersIncorrect inaccessibility warnings with impredicative types and GADTsConsider this code:
```haskell
{-# LANGUAGE ImpredicativeTypes #-}
{-# LANGUAGE GADTs #-}
data AB a where
A :: (x ~ (forall a b. a -> b -> b)) => x -> AB x
B :: (x ~ (forall p. p -> forall q. q -> q)) => x -> AB x
data SomeAB = fo...Consider this code:
```haskell
{-# LANGUAGE ImpredicativeTypes #-}
{-# LANGUAGE GADTs #-}
data AB a where
A :: (x ~ (forall a b. a -> b -> b)) => x -> AB x
B :: (x ~ (forall p. p -> forall q. q -> q)) => x -> AB x
data SomeAB = forall x. SomeAB (AB x)
showAB :: SomeAB -> String
showAB (SomeAB A{}) = "A"
showAB (SomeAB B{}) = "B"
main = putStrLn (showAB (SomeAB (A @(forall a b. a -> b -> b) (\_ x -> x))))
```
Gives the warnings:
```
S.hs:15:1: warning: [GHC-94210] [-Woverlapping-patterns]
Pattern match has inaccessible right hand side
In an equation for ‘showAB’: showAB (SomeAB A {}) = ...
|
15 | showAB (SomeAB A{}) = "A"
| ^^^^^^^^^^^^^^^^^^^^^^^^^
S.hs:15:16: warning: [GHC-40564] [-Winaccessible-code]
• Inaccessible code in
a pattern with constructor:
A :: forall x. (x ~ (forall a b. a -> b -> b)) => x -> AB x,
in an equation for ‘showAB’
Couldn't match type ‘x’ with ‘forall a b. a -> b -> b’
Cannot equate type variable ‘x’
with a type involving polytypes: forall a b. a -> b -> b
‘x’ is a rigid type variable bound by
a pattern with constructor: SomeAB :: forall x. AB x -> SomeAB,
in an equation for ‘showAB’
at S.hs:15:9-18
• In the pattern: A {}
In the pattern: SomeAB A {}
In an equation for ‘showAB’: showAB (SomeAB A {}) = "A"
|
15 | showAB (SomeAB A{}) = "A"
| ^^^
S.hs:16:1: warning: [GHC-53633] [-Woverlapping-patterns]
Pattern match is redundant
In an equation for ‘showAB’: showAB (SomeAB B {}) = ...
|
16 | showAB (SomeAB B{}) = "B"
| ^^^^^^^^^^^^^^^^^^^^^^^^^
S.hs:16:16: warning: [GHC-40564] [-Winaccessible-code]
• Inaccessible code in
a pattern with constructor:
B :: forall x.
(x ~ (forall p. p -> forall q. q -> q)) =>
x -> AB x,
in an equation for ‘showAB’
Couldn't match type ‘x’ with ‘forall p. p -> forall q. q -> q’
Cannot equate type variable ‘x’
with a type involving polytypes: forall p. p -> forall q. q -> q
‘x’ is a rigid type variable bound by
a pattern with constructor: SomeAB :: forall x. AB x -> SomeAB,
in an equation for ‘showAB’
at S.hs:16:9-18
• In the pattern: B {}
In the pattern: SomeAB B {}
In an equation for ‘showAB’: showAB (SomeAB B {}) = "B"
|
16 | showAB (SomeAB B{}) = "B"
| ^^^
```
But it runs just fine and prints:
```
A
```
## Expected behavior
No warnings.
## Environment
* GHC version used: GHC 9.2.6 and GHC 9.6.1sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23145Incorrect non-exhaustive pattern match warning with higher rank types2023-05-24T07:01:31ZJaro ReindersIncorrect non-exhaustive pattern match warning with higher rank types## Summary
I was experimenting with some very impredicative types when I got a seemingly redundant warning.
## Steps to reproduce
```haskell
{-# LANGUAGE ImpredicativeTypes #-}
data Freer c0 f a = Pure (c0 a) | forall x. Freer (f x) (...## Summary
I was experimenting with some very impredicative types when I got a seemingly redundant warning.
## Steps to reproduce
```haskell
{-# LANGUAGE ImpredicativeTypes #-}
data Freer c0 f a = Pure (c0 a) | forall x. Freer (f x) (forall c. c x -> Freer c f a)
bind :: (forall c. Freer c f a) -> (forall c. c a -> Freer c f b) -> (forall c. Freer c f b)
bind (Pure x) k = k x
bind (Freer op k) k' = Freer op (kcompose k' k)
kcompose :: (forall c. c y -> Freer c f z) -> (forall c. c x -> Freer c f y) -> (forall c. c x -> Freer c f z)
kcompose k1 k2 x =
case k2 x of
Pure y -> k1 y
Freer op k3 -> Freer op (kcompose k1 k3)
```
This gave me the warning:
```
Pattern match(es) are non-exhaustive
In an equation for ‘bind’:
Patterns of type ‘forall (c :: k -> *). Freer c f a’,
‘forall (c :: k -> *). c a -> Freer c f b’ not matched:
_ _
```
## Expected behavior
I expected no warnings.
## Environment
* GHC version used: 9.4.4https://gitlab.haskell.org/ghc/ghc/-/issues/23007Data family instances shouldn't trigger unused type patterns2023-06-15T22:21:21ZLas SafinData family instances shouldn't trigger unused type patterns## Summary
Data types definitions don't trigger unused type patterns when
there is an unused type variable, yet data instances do,
somewhat expectedly, trigger this.
See example below.
## Steps to reproduce
```haskell
{-# LANGUAGE GH...## Summary
Data types definitions don't trigger unused type patterns when
there is an unused type variable, yet data instances do,
somewhat expectedly, trigger this.
See example below.
## Steps to reproduce
```haskell
{-# LANGUAGE GHC2021 #-}
{-# LANGUAGE TypeFamilies #-}
{-# OPTIONS_GHC -Wunused-type-patterns #-}
import Data.Kind (Type)
data family D (f :: Type) :: Type -> Type
data MyConst (a :: Type)
newtype instance D (MyConst a) b = MyConst a
```
`b` triggers the unused type pattern warning.
It is in one sense unused: it doesn't appear on the RHS,
yet in another sense, it is used. If we write `_b` as the
warning wants, we get the following behaviour:
```haskell
:t MyConst
MyConst :: a -> D (MyConst a) _b
```
Is `_b` used here? If not, why does `data Const a b = Const a` not
trigger the warning?
# Expected behavior
I suggest either making the warning more lenient, or perhaps
adding a new warning.
I am not sure when someone would want the old behaviour.
The whole reason for why this is useful is that in function definitions,
an unused argument often means you forgot to account for something.
Marking it with a `_` marks that you _aren't_ supposed to use it.
This applies to type families too, but not to data families I would say:
If you forget to use a type variable, code that uses the instance will fail entirely
as the constructors are wrong, hence we don't need the warning.
## Environment
* GHC version used: GHC 9.2.4Las SafinLas Safinhttps://gitlab.haskell.org/ghc/ghc/-/issues/22900GHC warns about non-exhaustive pattern match of Word82023-02-08T13:23:42ZOleg GrenrusGHC warns about non-exhaustive pattern match of Word8```haskell
import Data.Word
foo :: Word8 -> Bool
foo 0x00 = True
foo 0x01 = True
foo 0x02 = True
foo 0x03 = True
...
foo 0xFF = True
```
Is exhaustive, one can test that with
```haskell
test = map foo [ minBound .. maxBound ]
```
How...```haskell
import Data.Word
foo :: Word8 -> Bool
foo 0x00 = True
foo 0x01 = True
foo 0x02 = True
foo 0x03 = True
...
foo 0xFF = True
```
Is exhaustive, one can test that with
```haskell
test = map foo [ minBound .. maxBound ]
```
However, GHC seems to disagree an issues a warning.
Complete file is in attachment.
[demo.hs](/uploads/cbb03615afa83b68de37b5f643b8579e/demo.hs)https://gitlab.haskell.org/ghc/ghc/-/issues/22855No dead code warning for `if (x:: Word) < 0 then putStrLn "dead" else putStrL...2023-02-22T11:53:07ZDaneel S. YaitskovNo dead code warning for `if (x:: Word) < 0 then putStrLn "dead" else putStrLn "live"Following code is optimized and dead branch doesn't end up in an elf file, but
compiler doesn't complain about anything with -Wall.
```haskell
f :: Word -> IO Word
f x | x < 0 = putStrLn "DDDDDDDDDDDDDDDDDDDDDDDDDD" >> pure 1
| oth...Following code is optimized and dead branch doesn't end up in an elf file, but
compiler doesn't complain about anything with -Wall.
```haskell
f :: Word -> IO Word
f x | x < 0 = putStrLn "DDDDDDDDDDDDDDDDDDDDDDDDDD" >> pure 1
| otherwise = pure $ x + 2
{-# NOINLINE f #-}
```
GHC 9.2.4https://gitlab.haskell.org/ghc/ghc/-/issues/22683Collect occurences of incomplete patterns to make them available to Haddock2023-01-17T15:27:09ZHécate MoonlightCollect occurences of incomplete patterns to make them available to HaddockI feel like this is a relatively "easy" win that we can take from Idris (without having to solve the halting problem). From the Idris documentation:
> By default, functions in Idris must be covering. That is, there must be patterns whic...I feel like this is a relatively "easy" win that we can take from Idris (without having to solve the halting problem). From the Idris documentation:
> By default, functions in Idris must be covering. That is, there must be patterns which cover all possible values of the inputs types. For example, the following definition will give an error:
>
> ```idris
> fromMaybe : Maybe a -> a
> fromMaybe (Just x) = x
> ```
>
> This gives an error because fromMaybe Nothing is not defined. Idris reports:
>
> ```
> frommaybe.idr:1:1--2:1:fromMaybe is not covering. Missing cases:
> fromMaybe Nothing
> ```
>
> You can override this with a partial annotation:
>
> ```idris
> partial fromMaybe : Maybe a -> a
> fromMaybe (Just x) = x
> ```
>
> However, this is not advisable, and in general you should only do this during the initial development of a function, or during debugging. If you try to evaluate fromMaybe Nothing at run time you will get a run time error.
-- https://idris2.readthedocs.io/en/latest/tutorial/typesfuns.html#totality-and-covering
Beyond the usual benefits, it powers the documentation generation tool:
![Screenshot_2022-12-27_at_20-45-42_Data.List](/uploads/22b8349c373d1126ec6d5e590cbe195c/Screenshot_2022-12-27_at_20-45-42_Data.List.png)
We can't yet carry proof for pre-conditions that would guarantee totality in a function that is partial, but we can certainly start by exposing this meta-data about a function: Has the function triggered a `-Wincomplete-patterns` warning?https://gitlab.haskell.org/ghc/ghc/-/issues/22652GHC 9.2/9.4 -Wincomplete-patterns regression with GADTs2023-03-23T13:39:35ZlierdakilGHC 9.2/9.4 -Wincomplete-patterns regression with GADTs## Summary
Totality checker seemingly regressed from 9.0 to GHC 9.2 and 9.4, specifically with GADTs and type families.
Consider this code.
```haskell
{-# LANGUAGE DataKinds, TypeFamilies, GADTs #-}
{-# OPTIONS_GHC -Wincomplete-patter...## Summary
Totality checker seemingly regressed from 9.0 to GHC 9.2 and 9.4, specifically with GADTs and type families.
Consider this code.
```haskell
{-# LANGUAGE DataKinds, TypeFamilies, GADTs #-}
{-# OPTIONS_GHC -Wincomplete-patterns -Werror #-}
module Bug where
data T = Z | S
data ST n where
SZ :: ST Z
SS :: ST S
type family F n where
F Z = Z
F S = Z
f :: F m ~ n => ST m -> ST n -> ()
f _ SZ = ()
```
(I tried to cut this down as much as possible, in the original context this happened with typelevel Peano arithmetic with singleton proofs)
Now, reasonably speaking, these patterns are complete, `n` must be `Z` due to the constraint, regardless of what `m` is, hence the value can only be `SZ`, and GHC 9.0.2 is indeed able to infer that. GHC 9.2.5 and 9.4.3, however, fail to, reporting missing patterns:
```
$ ghc-9.0 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
$ ghc-9.2 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:17:1: error: [-Wincomplete-patterns, -Werror=incomplete-patterns]
Pattern match(es) are non-exhaustive
In an equation for ‘f’:
Patterns of type ‘ST m’, ‘ST n’ not matched: _ SS
|
17 | f _ SZ = ()
| ^^^^^^^^^^^
$ ghc-9.4 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
-- same as above
```
I can silence this by adding `f x SS = case x of`, but that's pretty ugly.
Does not reproduce if type family is trivial (i.e. only has one case, or is reduced to one case by GHC). Does reproduce regardless whether the type family is open or closed.
## Steps to reproduce
```
ghc-9.2 Bug.hs
```
## Expected behavior
Not produce redundant pattern warnings.
## Environment
* GHC version used: reproduces on 9.2.5, 9.4.3
***
## Additional information
There is another example I found where GHC 9.2 finds incomplete patterns when GHC 9.0 doesn't, but it seems it's rather a bug in GHC 9.0! Still, for the sake of thoroughness:
```haskell
{-# LANGUAGE DataKinds, TypeFamilies, GADTs #-}
{-# OPTIONS_GHC -Wincomplete-patterns -Werror #-}
module OldBug where
data T = TInt | TVoid
data AST t where
VInt :: Int -> AST TInt
data ST t where
STInt :: ST TInt
STVoid :: ST TVoid
f :: ST t -> AST t -> ()
f STInt _ = ()
```
Note that this pattern **is not**, in fact, complete: `f STVoid undefined` will lead to "incomplete patterns" error at runtime. I would argue we want to **keep** the current 9.2/9.4 behaviour for this case.
```
$ ghc-9.0 OldBug.hs
[1 of 1] Compiling OldBug ( OldBug.hs, OldBug.o )
$ ghc-9.2 OldBug.hs
[1 of 1] Compiling OldBug ( OldBug.hs, OldBug.o )
OldBug.hs:16:1: error: [-Wincomplete-patterns, -Werror=incomplete-patterns]
Pattern match(es) are non-exhaustive
In an equation for ‘f’:
Patterns of type ‘ST t’, ‘AST t’ not matched: STVoid _
|
16 | f STInt _ = ()
| ^^^^^^^^^^^^^^
$ ghc-9.4 OldBug.hs
-- same as above
```Sebastian GrafSebastian Grafhttps://gitlab.haskell.org/ghc/ghc/-/issues/22511GHC 9.2 warns about code that 8.10 accepts2022-11-29T15:39:57ZErik de Castro LopoGHC 9.2 warns about code that 8.10 accepts## Summary
The code in the reproducer issues a warning in ghc-9.2 but not in ghc-8.10.
Related to https://gitlab.haskell.org/ghc/ghc/-/issues/15656
## Steps to reproduce
```haskell
{-# OPTIONS_GHC -Wno-unused-top-binds #-}
-- Build ...## Summary
The code in the reproducer issues a warning in ghc-9.2 but not in ghc-8.10.
Related to https://gitlab.haskell.org/ghc/ghc/-/issues/15656
## Steps to reproduce
```haskell
{-# OPTIONS_GHC -Wno-unused-top-binds #-}
-- Build with `ghc -Wall -Werror reproducer.hs -o reproducer`
-- Data structures cargo culted from `aeson` library and then minimised.
data SumEncoding
= TaggedObject { tagFieldName :: String, contentsFieldName :: String }
| UntaggedValue
data Options = Options
{ sumEncoding :: SumEncoding
}
defaultOptions :: Options
defaultOptions =
Options { sumEncoding = defaultTaggedObject }
defaultTaggedObject :: SumEncoding
defaultTaggedObject =
TaggedObject { tagFieldName = "tag", contentsFieldName = "contents" }
encodingOptions :: Options
encodingOptions = defaultOptions
{ sumEncoding =
defaultTaggedObject
{ tagFieldName = "kind"
}
}
main :: IO ()
main = putStrLn "Hello, World!"
```
Builds fine with `ghc-8.10.7` and with `ghc-9.2.4` warns:
```
reproducer.hs:29:7: error: [-Wincomplete-record-updates, -Werror=incomplete-record-updates]
Pattern match(es) are non-exhaustive
In a record-update construct:
Patterns of type ‘SumEncoding’ not matched: UntaggedValue
|
29 | defaultTaggedObject
| ^^^^^^^^^^^^^^^^^^^...
```
## Expected behavior
Do not expect a warning from this code.
## Environment
* GHC version used: 8.10.7 and 9.2.4https://gitlab.haskell.org/ghc/ghc/-/issues/22101Redundant constraint warning does not account for pattern checking2022-09-23T21:47:18ZDavid FeuerRedundant constraint warning does not account for pattern checking## Summary
Constraints that are only required for pattern checking are falsely reported as redundant.
## Steps to reproduce
```haskell
{-# language DataKinds, GADTs, TypeOperators, AllowAmbiguousTypes #-}
{-# options_ghc -Wall -Wredun...## Summary
Constraints that are only required for pattern checking are falsely reported as redundant.
## Steps to reproduce
```haskell
{-# language DataKinds, GADTs, TypeOperators, AllowAmbiguousTypes #-}
{-# options_ghc -Wall -Wredundant-constraints #-}
import Data.Type.Bool
import Data.Type.Equality
-- | Singletons for 'Bool'
data SBool b where
SFalse :: SBool 'False
STrue :: SBool 'True
-- | If a disjunction is false, so is its left argument.
orL :: (a || b) ~ 'False => SBool a -> a :~: 'False
orL SFalse = Refl
```
GHC tells me the `(a || b) ~ 'False` constraint is redundant.
## Expected behavior
I expect the above to compile without warnings.
## Discussion
The constraint is redundant—for type checking: `orR` will pass the type checker if it's removed. However, it's *not* redundant for pattern checking—the pattern checker will produce a warning if it's removed. Is there a way to account for which constraints the pattern checker "uses", and avoid warning about ones that it does?
## Environment
* GHC version used: 9.4.1
Optional:
* Operating System:
* System Architecture:https://gitlab.haskell.org/ghc/ghc/-/issues/21795MINIMAL pragmas can't express empty method set2022-07-27T07:44:51ZBen GamariMINIMAL pragmas can't express empty method setThe `MINIMAL` pragma allows the user to define a set a typeclass methods which are sufficient to fully define an instance. However, currently it offers no way to express the empty set, which may arise when all of a class's methods have d...The `MINIMAL` pragma allows the user to define a set a typeclass methods which are sufficient to fully define an instance. However, currently it offers no way to express the empty set, which may arise when all of a class's methods have default definitions. This should be fixed.https://gitlab.haskell.org/ghc/ghc/-/issues/21660Pattern match checker should suggest constructors in the range of view patter...2023-01-03T17:14:11ZSebastian GrafPattern match checker should suggest constructors in the range of view pattern instead of the domainConsider
```hs
data D = InternalConstructorIDon'tWannaHearAbout Int Bool Char
predicate :: D -> Bool
predicate (InternalConstructorIDon'tWannaHearAbout i b c) = i >= 0 && b
foo :: D -> Int
foo (predicate -> False) = 3
```
Today, we'l...Consider
```hs
data D = InternalConstructorIDon'tWannaHearAbout Int Bool Char
predicate :: D -> Bool
predicate (InternalConstructorIDon'tWannaHearAbout i b c) = i >= 0 && b
foo :: D -> Int
foo (predicate -> False) = 3
```
Today, we'll report
```
test.hs:12:1: warning: [-Wincomplete-patterns]
Pattern match(es) are non-exhaustive
In an equation for ‘foo’: Patterns of type ‘D’ not matched: _
|
12 | foo (predicate -> False) = 3
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
and that is rather unhelpful. GHC 9.0 (and I'd expect 9.2 to do so, too) even repported
```
test.hs:12:1: warning: [-Wincomplete-patterns]
Pattern match(es) are non-exhaustive
In an equation for ‘foo’:
Patterns not matched: InternalConstructorIDon'tWannaHearAbout _ _ _
|
12 | foo (predicate -> False) = 3
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
mentioning the unhelpful constructor of `D`.
# Proposal
If there's a view pattern involved, try to report missed patterns in the range of that pattern instead:
```
test.hs:12:1: warning: [-Wincomplete-patterns]
Pattern match(es) are non-exhaustive
In an equation for ‘foo’:
Patterns not matched: predicate -> True
|
12 | foo (predicate -> False) = 3
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Open question: What should happen if both view patterns and regular patterns are used? Should we report patterns in the range or the domain? Not sure. In effect, we are trying to decide from which COMPLETE set to report: Either the one from the range (`Bool`) or the one from the domain (`D`).
(In that way, this ticket is related to https://gitlab.haskell.org/ghc/ghc/-/issues/20311 where @sheaf first reported this example. We probably never want to report patterns from the domain if it's comprised of non-exported constructors.)
# Challenges
We'd have to identify which pattern variable is associated with the range of a view pat, to be able to "un-desugar" in our reporting mechanism later on.
I don't have time to work on this, but I'd be happy to advise.https://gitlab.haskell.org/ghc/ghc/-/issues/21572[Feature Request] Can GHC report implicit constructor matches?2022-07-19T07:57:26ZLevent Erkök[Feature Request] Can GHC report implicit constructor matches?## Motivation
In long running projects, it is common that a new constructor gets added to an existing data-type. The question then becomes what parts of the code we need to modify to support this new constructor. It would be great if th...## Motivation
In long running projects, it is common that a new constructor gets added to an existing data-type. The question then becomes what parts of the code we need to modify to support this new constructor. It would be great if there was a way for ghc (or `ghci`) to report, for a given constructor, all locations where the program implicitly matches against it, i.e., the constructor gets matched against a wildcard.
This facility would greatly aid in code maintenance and refactoring tasks.
## Proposal
Consider a data-type with lots of constructors:
```
data X = X1 | X2 | ... | Xn
```
we might have many places that only care for a few of these:
```
f X1 = rhs1
f X2 = rhs2
f _ = error "can't happen"
```
or
```
case expr of
X1 -> rhs1
X5 -> rhs2
_ -> error "can't happen"
```
If we now add a new constructor `XK` that didn't exist before, we'd like GHC to tell us where in our code this constructor is implicitly matched; so we can review and decide if the "ignoring" behavior is OK, or we should add relevant code.
Obviously, this should work just the same if the constructor has arguments, matched in a nested way, etc. I imagine it might be a ghci command:
```
:implicit_match XK
```
or perhaps a ghc command-line option which spits out a report. The details aren't particularly important and if implemented, the implementors can choose the most appropriate design.
# Objections
When these sorts of requests come, it is common for people to point out that this may not be possible in general. And indeed, I do not expect GHC to give a precise answer: It might report false positives (i.e., where the constructor wouldn't be matched, but it'd still be reported as such due to data-path considerations), or false negatives (i.e., the constructor would be matched, but the analysis gets fooled for some reason.)
And that's perfectly fine! Nobody is expecting for this analysis to be 100% accurate. Just like the current pattern-match warnings, the output of this command (in ghci), or analysis printed by ghc might be an over/under-approximation.
_Just because the problem is unsolvable in general, doesn't mean the information GHC will provide will be useless; quite to the contrary, it'd go along way for code maintenance in both industrial and academic contexts._ If necessary, the output of the command can have a disclaimer to the same effect.https://gitlab.haskell.org/ghc/ghc/-/issues/21451GHC 9.0 or later gives duplicate -Wincomplete-uni-patterns warnings2023-01-03T17:01:59ZRyan ScottGHC 9.0 or later gives duplicate -Wincomplete-uni-patterns warningsConsider this program:
```hs
{-# OPTIONS_GHC -Wincomplete-uni-patterns #-}
module Bug where
a, b, c :: Bool
a = False
b = False
c = False
mx :: Maybe ()
mx = Just ()
f :: ()
f | a = ()
| otherwise
= let Just x = mx
in x
```
...Consider this program:
```hs
{-# OPTIONS_GHC -Wincomplete-uni-patterns #-}
module Bug where
a, b, c :: Bool
a = False
b = False
c = False
mx :: Maybe ()
mx = Just ()
f :: ()
f | a = ()
| otherwise
= let Just x = mx
in x
```
If you compile this, you'll get an `-Wincomplete-uni-patterns` warning, as expected:
```
$ ghc-9.2 Bug.hs -fforce-recomp
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:15:9: warning: [-Wincomplete-uni-patterns]
Pattern match(es) are non-exhaustive
In a pattern binding:
Patterns of type ‘Maybe ()’ not matched: Nothing
|
15 | = let Just x = mx
| ^^^^^^^^^^^
```
Now change the definition of `f` so that its first guard is predicated on both `a` and `b`:
```hs
f :: ()
f | a, b = ()
| otherwise
= let Just x = mx
in x
```
This time, the warning will look strange:
```
$ ghc-9.2 Bug.hs -fforce-recomp
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:15:9: warning: [-Wincomplete-uni-patterns]
Pattern match(es) are non-exhaustive
In a pattern binding:
Patterns of type ‘Maybe ()’ not matched:
Nothing
Nothing
|
15 | = let Just x = mx
| ^^^^^^^^^^^
```
Notice that there are duplicate warnings about the `Nothing` pattern! In fact, the more conjuncts you add, the more duplicates there will be. For instance, making the first guard be `| a, b, c` will result in a total of three warnings about `Nothing`.
Ideally, we'd only have just one warning about `Nothing`. In fact, this was the behavior prior to GHC 9.0:
```
$ ghc-8.10 Bug.hs -fforce-recomp
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:15:9: warning: [-Wincomplete-uni-patterns]
Pattern match(es) are non-exhaustive
In a pattern binding: Patterns not matched: Nothing
|
15 | = let Just x = mx
| ^^^^^^^^^^^
```
This regression was introduced at some point between GHC 8.10 and 9.0, as 9.0 is the first version to exhibit the bug.https://gitlab.haskell.org/ghc/ghc/-/issues/20896Unexpected warning "redundant constraint" when a Constraint type family is us...2022-09-23T21:47:17ZEvgeny PoberezkinUnexpected warning "redundant constraint" when a Constraint type family is used to limit GADT patterns## Summary
GHC shows a warning "redundant constraint" when a total type family of kind Constraint is used to reduce the list of GADT constructors that have to be used for a complete pattern match.
## Steps to reproduce
```haskell
{-# ...## Summary
GHC shows a warning "redundant constraint" when a total type family of kind Constraint is used to reduce the list of GADT constructors that have to be used for a complete pattern match.
## Steps to reproduce
```haskell
{-# LANGUAGE GADTs, KindSignatures, DataKinds, ConstraintKinds, TypeFamilies #-}
import Data.Kind
main :: IO ()
main = print $ f SA SC
data T1 = A | B
data T2 = C | D
data ST1 (a :: T1) where
SA :: ST1 'A
SB :: ST1 'B
data ST2 (b :: T2) where
SC :: ST2 'C
SD :: ST2 'D
type family Compatible (a :: T1) (b :: T2) :: Constraint where
Compatible 'A 'C = ()
Compatible 'A 'D = ()
Compatible 'B 'D = ()
Compatible _ _ = Int ~ Bool
f :: Compatible a b => ST1 a -> ST2 b -> Int
f SA SC = 0
f SA SD = 1
f SB SD = 2
```
GHC warning: `Redundant constraint: Compatible a b`
Removing the constraint makes pattern match incomplete, so it is not redundant.
## Expected behavior
No GHC warning
## Environment
* GHC version used: 8.10.7
Optional:
* Operating System: MacOS
* System Architecture: x86https://gitlab.haskell.org/ghc/ghc/-/issues/20883Different -Woverlapping-patterns warnings in GHCi versus compiled code2023-08-31T13:05:37ZRyan ScottDifferent -Woverlapping-patterns warnings in GHCi versus compiled codeIn the following code:
```hs
{-# OPTIONS_GHC -Woverlapping-patterns #-}
module Bug where
f :: Int
f | id (id True)
= 1
| id (id True)
, True
= 2
| otherwise
= 3
```
The second guard is definitely redundant, and GHC 9.0.1...In the following code:
```hs
{-# OPTIONS_GHC -Woverlapping-patterns #-}
module Bug where
f :: Int
f | id (id True)
= 1
| id (id True)
, True
= 2
| otherwise
= 3
```
The second guard is definitely redundant, and GHC 9.0.1 and later recognize this when compiled normally:
```
$ ghc-9.0.1 Bug.hs -fforce-recomp
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:8:5: warning: [-Woverlapping-patterns]
Pattern match is redundant
In an equation for ‘f’: f | id (id True), True = ...
|
8 | | id (id True)
| ^^^^^^^^^^^^
```
When loaded into GHCi, however, the warning does not occur for some reason:
```
$ ghci-9.0.1 Bug.hs
GHCi, version 9.0.1: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Ok, one module loaded.
```
I would expect both modes to produce the same warnings.
cc @sgraf812