check_overlap panic (7.1 regression)

The attached program is rightfully rejected by GHC 7.0.4 (with "Could not deduce (HMapClass f l) ...") but makes GHC HEAD panic:

$ ghc-7.3.20110713 Overlap.hs 
[1 of 1] Compiling Overlap          ( Overlap.hs, Overlap.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.3.20110713 for x86_64-unknown-linux):
	check_overlap
    main:Overlap.HDropClass{tc raS}
      main:Overlap.PZero{tc raZ}
      (main:Overlap.HMap{tc raN} f{tv adi} [sk] l{tv adk} [sk])

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Both versions are built with the devel2 BuildFlavour.

Trac metadata

Trac field	Value
Version	7.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import labels

Attached file Overlap.hs ($608).

Harump. I'll fix the crash, but it does expose a little problem. Consider this program

{-# LANGUAGE FlexibleInstances, FlexibleContexts, 
             ScopedTypeVariables, MultiParamTypeClasses, TypeFamilies #-}

module Foo where

class C a b where op :: a -> b
instance C Int b
type family F a

f :: forall w. C Int w => Int -> w -> F Int
f x y = op x :: F Int

The call of op gives rise to a wanted constraint (C Int (F Int)) which you would think would be satisfied from the (C Int b) instance declaration. But actually we get this:

Foo.hs:10:9:
    Overlapping instances for C Int (F Int)
      arising from a use of `op'
    Matching instances: instance C Int b -- Defined at Foo.hs:6:10-16
    There exists a (perhaps superclass) match:
      from the context (C Int w)
        bound by the type signature for f :: C Int w => Int -> w -> F Int
        at Foo.hs:10:1-21

GHC is saying (a bit stupidly) that (C Int (F Int)) might ultimately reduce, by evaluating the call to F, to (C Int w), which could be satisfied from the constraint in the signature rather than the instance declaration. Of course, it can't. But it wouldn't have been so stupid if the program had been

g :: forall w. C Int w => Int -> w -> F [w]
g x y = op x :: F [w]

Now it's not so stupid; (F [w]) might indeed reduce to w.

But it's delicate, and may end up rejecdting a program that really should be accepted (like f). Not sure what to do here.

mentioned in commit 7689e566

Can we safely ignore an overlap in case of "wildcard" (in the parameter(s) in question) instances like C Int b?

If yes, then the instance C Int (B b) could be considered a "wildcard" for resolving the potential overlap between C Int (B w) and C Int (B (F [w])). And so on.

Ian: can you merge the change to 7.2 anyway, pls?

Now I'm getting

ghc: panic! (the 'impossible' happened)
  (GHC version 7.3.20110718 for x86_64-unknown-linux):
	ASSERT failed! file compiler/typecheck/TcErrors.lhs, line 590

after the "Overlapping instances ..." message.

Ah, sorry. I've pushed a fix

commit f272d03a64329abdc28613a24f193bef7080db5a
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Mon Jul 18 13:54:00 2011 +0100

    Remove bogus ASSERT

 compiler/typecheck/TcErrors.lhs |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

added 1 deleted label

Merged as changeset:b72f0df9 and changeset:2648e205

I'll leave the ticket open for the "underlying delicate point".

removed 1 deleted label

changed milestone to %7.6.1

assigned to @simonpj

changed milestone to %7.6.2

changed milestone to %7.10.1

Moving to 7.10.1.

Trac metadata

Trac field	Value
Component	Compiler → Compiler (Type checker)

removed milestone

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

changed milestone to %8.0.1

Milestone renamed

added compiler crash label

added Pnormal label