Opened 7 months ago

Last modified 6 months ago

#16289 new bug

GHC thinks pattern match is exhaustive

Reported by: dnspies Owned by:
Priority: high Milestone:
Component: Compiler Version: 8.6.3
Keywords: PatternMatchWarnings Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


{-# OPTIONS_GHC -Werror #-}

module Lib where

data Value = Finite Integer | Infinity
  deriving (Eq)

instance Num Value where
  (+)         = undefined
  (*)         = undefined
  abs         = undefined
  signum      = undefined
  negate      = undefined
  fromInteger = Finite

isSpecial :: Value -> Bool
isSpecial Infinity = True
isSpecial 0        = True
isSpecial 1        = True
isSpecial _        = False

> ghc Lib.hs
[1 of 1] Compiling Lib              ( Lib.hs, Lib.o )

Lib.hs:19:1: error: [-Woverlapping-patterns, -Werror=overlapping-patterns]
    Pattern match is redundant
    In an equation for ‘isSpecial’: isSpecial 1 = ...
19 | isSpecial 1        = True
   | ^^^^^^^^^^^^^^^^^^^^^^^^^

Lib.hs:20:1: error: [-Woverlapping-patterns, -Werror=overlapping-patterns]
    Pattern match is redundant
    In an equation for ‘isSpecial’: isSpecial _ = ...
20 | isSpecial _        = False
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^

Change History (4)

comment:1 Changed 7 months ago by goldfire

Priority: normalhigh

That's pretty frightening. I'm bumping priority, but anyone can feel free to disagree with that judgment.

comment:2 Changed 7 months ago by simonpj

Keywords: PatternMatchWarnings added

comment:3 Changed 7 months ago by harpocrates

This looks suspiciously like (that's about overloaded strings, but otherwise pretty much the same situation). There's something fishy about exhaustiveness checking on overloaded literals in general.

comment:4 Changed 6 months ago by Marge Bot <ben+marge-bot@…>

In 4626cf2/ghc:

Fix Uncovered set of literal patterns

Issues #16289 and #15713 are proof that the pattern match checker did
an unsound job of estimating the value set abstraction corresponding to
the uncovered set.

The reason is that the fix from #11303 introducing `NLit` was
incomplete: The `LitCon` case desugared to `Var` rather than `LitVar`,
which would have done the necessary case splitting analogous to the
`ConVar` case.

This patch rectifies that by introducing the fresh unification variable
in `LitCon` in value abstraction position rather than pattern postition,
recording a constraint equating it to the constructor expression rather
than the literal. Fixes #16289 and #15713.
Note: See TracTickets for help on using tickets.