Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#8978 closed bug (fixed)

Type synonyms in class associated types behave strangely

Reported by: joelteon Owned by:
Priority: highest Milestone: 7.8.2
Component: Compiler Version: 7.8.1
Keywords: Cc: eir@…, ghc@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHC rejects valid program Test Case: indexed-types/should_compile/T8978
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE TypeFamilies #-}

type Syn a = Associated a

class Eq (Associated a) => Foo a where
    type Associated a :: *
    foo :: a -> Syn a -> Bool

instance Foo () where
    type Associated () = Int
    foo _ x = x == x

In 7.6.3 and 7.8.1-rc2, this file compiles. In 7.8.1 release, GHC produces this error:

    No instance for (Eq (Syn ())) arising from a use of ‘==’
    In the expression: x == x
    In an equation for ‘foo’: foo _ x = x == x
    In the instance declaration for ‘Foo ()’

even though there is an Eq instance for Associated (), and Syn is just a type synonym.

Change History (19)

comment:1 Changed 5 years ago by joelteon

Summary: Type synonyms are not *exactly* synonymsType synonyms in class associated types behave strangely

comment:2 Changed 5 years ago by goldfire

Cc: eir@… added

I just got bit by this, too, on code that worked with 7.8.1 RC2. A perusal through a -ddump-tc-trace makes it look like something in the constraint solver, but I could be wrong.

An easy workaround (if you wrote the type synonym) is to use a one-equation type family instead.

comment:3 Changed 5 years ago by goldfire

comment:4 Changed 5 years ago by Lemming

Cc: ghc@… added

You can find another example in #8979.

comment:5 in reply to:  2 Changed 5 years ago by Lemming

Replying to goldfire:

An easy workaround (if you wrote the type synonym) is to use a one-equation type family instead.

That helped. Thanks for the suggestion!

comment:6 Changed 5 years ago by joelteon

The single-equation solution fixes this particular problem, but this is a simplification of library code that's throwing this error now, in which the type family cannot be closed.

comment:7 Changed 5 years ago by goldfire

Sorry if I was unclear -- I meant to change the vanilla type synonym into a type family. My guess is that GHC won't care whether the new family is closed or open with one universal equation (if you need backward compatibility). You don't need to change the existing type family for my workaround.

comment:8 Changed 5 years ago by simonpj

Ugh. This is my fault; an egregious blunder in a (cool) clean-up of the type flattener. It's easy to fix (patch coming) but the bug is in the released 7.8.1. Will fix in 7.8.2. It just shows, you never have enough regression tests!

It affects any type synonym whose RHS mentions a type family. (Data families are fine.) Such as Syn above, or H in #8979.

Richard's workaround is good; use a type family instead.

Sorry about this.

Simon

comment:9 in reply to:  8 Changed 5 years ago by Lemming

Replying to simonpj:

Ugh. This is my fault; an egregious blunder in a (cool) clean-up of the type flattener. It's easy to fix (patch coming) but the bug is in the released 7.8.1. Will fix in 7.8.2. It just shows, you never have enough regression tests!

Will there be a "nightly snapshot build" for easy testing of the bugfix?

comment:10 Changed 5 years ago by snoyberg

This bug has apparently broken a number of my packages, and I'm not certain if all of them can be fixed in a way that's backwards compatible with GHC 7.4 and 7.6 (both of which I still support). Would it be possible to release 7.8.2 with this fix alone, instead of waiting a number of months for the release as would normally be done?

comment:11 Changed 5 years ago by Simon Peyton Jones <simonpj@…>

In b8132a9d2fdb93c5d30107b1d531dd73ac27b262/ghc:

Fix egregious blunder in the type flattener

In tidying up the flattener I introduced an error that no
regression test caught, giving rise to Trac #8978, #8979.
It shows up if you have a type synonym whose RHS mentions
type functions, such sas
     type family F a
     type T a = (F a, a)   -- This synonym isn't properly flattened

The fix is easy, but sadly the bug is in the released GHC 7.8.1

comment:12 Changed 5 years ago by simonpj

Yes, I'm afraid that if I really have broken a number of significant packages since RC2, we probably should make a quick 7.8.2. Who else has come across this?

Simon

comment:13 Changed 5 years ago by snoyberg

Thanks Simon. I'll be happy to do any testing of such a release.

comment:14 Changed 5 years ago by hvr

Milestone: 7.8.2
Priority: normalhighest

comment:15 Changed 5 years ago by thoughtpolice

Resolution: fixed
Status: newclosed

Merged in 7.8, thanks Simon.

comment:16 in reply to:  12 Changed 5 years ago by Lemming

Replying to simonpj:

Who else has come across this?

I encountered the bug when working on the tfp package. I could fix one problem within the package using the one-equation type family work-around. But the bug also affected the dependending llvm-tf package at several places. Thus I stopped working around and this means, that there might be more yet unseen places where it causes problems. Before a new release I would like very much to get a "nightly snapshot build" or "release candidate" for testing on 64-bit Linux. Otherwise I am afraid that the bugfix causes other subtle problems that will be part of 7.8.2.

comment:17 Changed 5 years ago by simonpj

The fix is merged on the 7.8.2 branch, so you can build it and try. I don't know if anyone has a pre-built binary distribution for your platform though.

comment:18 in reply to:  17 Changed 5 years ago by Lemming

Replying to simonpj:

The fix is merged on the 7.8.2 branch, so you can build it and try. I don't know if anyone has a pre-built binary distribution for your platform though.

I can confirm that the problems are gone with the ghc-7.8.1.20140410 built by Michael Snoyman.

comment:19 Changed 5 years ago by simonpj

Test Case: indexed-types/should_compile/T8978
Note: See TracTickets for help on using tickets.