Opened 11 years ago

Closed 9 months ago

Last modified 5 months ago

#322 closed bug (duplicate)

fromInteger-related pattern match overlap warnings

Reported by: ashley-y Owned by: simonpj
Priority: normal Milestone:
Component: Compiler Version: 6.4
Keywords: warnings Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: ds060
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by igloo)

The compiler incorrectly gives "Warning: Pattern match(es) are 
overlapped" for this file:

{-# OPTIONS -Werror #-}

module Buggy where

	instance (Num a) => Num (Maybe a) where
		(Just a) + (Just b) = Just (a + b)
		_ + _ = Nothing
		(Just a) - (Just b) = Just (a - b)
		_ - _ = Nothing
		(Just a) * (Just b) = Just (a * b)
		_ * _ = Nothing
		negate (Just a) = Just (negate a)
		negate _ = Nothing
		abs (Just a) = Just (abs a)
		abs _ = Nothing
		signum (Just a) = Just (signum a)
		signum _ = Nothing
		fromInteger = Just . fromInteger

	f :: Maybe Int -> Int
	f 1 = 1
	f Nothing = 2
	f _ = 3

Change History (12)

comment:1 Changed 10 years ago by nobody

Logged In: NO 

If we define the first line as:

f (Just 1) = 1

there is no problem. 

comment:2 Changed 10 years ago by igloo

  • Architecture set to Unknown
  • Description modified (diff)
  • difficulty set to Unknown
  • Keywords warnings added
  • Milestone set to _|_
  • Operating System set to Unknown
  • Test Case set to ds060

comment:3 Changed 9 years ago by simonmar

See #595

comment:4 Changed 8 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:5 Changed 8 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:6 Changed 6 years ago by marcotmarcot

  • Type of failure set to None/Unknown

I'm thinking about this bug, and the only way I can see to avoid it, is by knowing in compile-time, that is, when the compiler checks if the Patterns are complete, how the value (1 :: Integer) will be converted to (1 :: Maybe Int). This is defined in "fromInteger = Just . fromInteger", which is a user code. So the user code will have to be evaluated in compile time. Is this already done in any case? I don't think so, as this would create the possibility of the compilation not terminating.

comment:7 Changed 6 years ago by igloo

You can't make the warning perfect, but in cases where we are not sure we have 3 choices:

  • warn
  • don't warn
  • give a different warning, saying that we aren't sure (this warning could be en/disabled separately)

comment:8 Changed 3 years ago by monoidal

See also #8016

comment:9 Changed 2 years ago by Ian Lynagh <igloo@…>

In 50e451242b50bd57c5ad6268b97f6a480c24fe32/ghc:

Add test ds060 for trac #322 (bogus overlapping patterns warnings)

comment:10 Changed 2 years ago by Ian Lynagh <igloo@…>

In fef7a82c6897afb5196ca91a097c5d6b2462d4b7/ghc:

ds060 and ds061 are broken: trac #322, #851

comment:11 Changed 9 months ago by thomie

  • Resolution changed from None to duplicate
  • Status changed from new to closed

Because the existence of duplicate tickets makes doing a BugSweep of the bug tracker more cumbersome, I'm closing these tickets as duplicate. Don't worry, they're still listed on PatternMatchCheck, and will hopefully all be addressed by the work on #595 ("Overhaul GHC's overlapping/non-exhaustive pattern checking").

comment:12 Changed 5 months ago by George Karachalias <george.karachalias@…>

In 8a506104/ghc:

Major Overhaul of Pattern Match Checking (Fixes #595)

This patch adresses several problems concerned with exhaustiveness and
redundancy checking of pattern matching. The list of improvements includes:

* Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.).
  This fixes #4139, #3927, #8970 and other related tickets.

* Making the check laziness-aware. Cases that are overlapped but affect
  evaluation are issued now with "Patterns have inaccessible right hand side".
  Additionally, "Patterns are overlapped" is now replaced by "Patterns are
  redundant".

* Improved messages for literals. This addresses tickets #5724, #2204, etc.

* Improved reasoning concerning cases where simple and overloaded
  patterns are matched (See #322).

* Substantially improved reasoning for pattern guards. Addresses #3078.

* OverloadedLists extension does not break exhaustiveness checking anymore
  (addresses #9951). Note that in general this cannot be handled but if we know
  that an argument has type '[a]', we treat it as a list since, the instance of
  'IsList' gives the identity for both 'fromList' and 'toList'. If the type is
  not clear or is not the list type, then the check cannot do much still. I am
  a bit concerned about OverlappingInstances though, since one may override the
  '[a]' instance with e.g. an '[Int]' instance that is not the identity.

* Improved reasoning for nested pattern matching (partial solution). Now we
  propagate type and (some) term constraints deeper when checking, so we can
  detect more inconsistencies. For example, this is needed for #4139.

I am still not satisfied with several things but I would like to address at
least the following before the next release:
    Term constraints are too many and not printed for non-exhaustive matches
(with the exception of literals). This sometimes results in two identical (in
appearance) uncovered warnings. Unless we actually show their difference, I
would like to have a single warning.
Note: See TracTickets for help on using tickets.