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:

Description

{-# 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 https://ghc.haskell.org/trac/ghc/ticket/15713 (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.