Opened 3 years ago

Closed 2 years ago

#9575 closed bug (fixed)

-XAutoDeriveTypeable fails to generate instances

Reported by: hvr Owned by: dreixel
Priority: high Milestone: 7.8.4
Component: Compiler Version: 7.8.3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: deriving/should_compile/T8950
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

The following doesn't compile with GHC 7.8.3, but works with GHC HEAD. I couldn't find a matching ticket, so I don't know if this was fixed knowingly or not...

{-# LANGUAGE AutoDeriveTypeable #-}

import Data.Typeable (Typeable)

data T1 = C1 Int
     deriving (Eq,Ord)

tvoid :: Typeable a => a -> IO ()
tvoid _ = return ()

main :: IO ()
main = tvoid (C1 0)

...fails for GHC 7.8.3 with

    No instance for (Typeable T1) arising from a use of ‘tvoid’
    In the expression: tvoid (C1 0)
    In an equation for ‘main’: main = tvoid (C1 0)

I'm marking this with high priority, as it makes -XAutoDeriveTypeable unusable on GHC 7.8.3 as it stands.

Change History (9)

comment:1 Changed 3 years ago by dreixel

Owner: set to dreixel

Removing deriving (Eq,Ord) makes it compile. I'll have a closer look.

comment:2 Changed 3 years ago by rwbarton

See ticket:8950#comment:3.

I don't see what there is to gain by backporting a fix though, even if you could detect GHC 7.8.4, it's still more effort to do so than to just add Typeable to the deriving list. And it could break old code that uses AutoDeriveTypeable, by causing it to export more instances than it did under 7.8.3.

comment:3 Changed 3 years ago by dfeuer

It sounds to me like this ticket is mostly about making sure the necessary validation tests are in place.

comment:4 in reply to:  2 ; Changed 3 years ago by hvr

Replying to rwbarton:

See ticket:8950#comment:3.

I don't see what there is to gain by backporting a fix though, even if you could detect GHC 7.8.4, it's still more effort to do so than to just add Typeable to the deriving list. And it could break old code that uses AutoDeriveTypeable, by causing it to export more instances than it did under 7.8.3.

How would this break old code (unless orphan instances are involved) by exporting more instances?

However, at the very least this should be documented (unless it's easy enough to fix) as a known-bug in 7.8.4's manual (should 7.8.4 be ever be released). Or GHC 7.8.4 could even warn when -XAutoDeriveTypeable is used to raise awareness, that it doesn't work as advertised in GHC 7.8, so people don't start using it next year with GHC 7.10 (where it works as intended), and then assume it worked in GHC 7.8 as well. Alas, missing instances like Typeable go easily undetected in libraries.

And fwiw, you can discriminate GHC 7.8.4 quite easily via Cabal's if impl(ghc>=7.8.4) ... conditionals...

comment:5 in reply to:  4 Changed 3 years ago by rwbarton

Replying to hvr:

How would this break old code (unless orphan instances are involved) by exporting more instances?

Yes, I mean with orphan instances.

comment:6 Changed 3 years ago by dreixel

Test Case: deriving/should_compile/T8950

deriving/should_compile/T8950 already tests for this.

comment:7 Changed 3 years ago by thoughtpolice

Milestone: 7.8.47.10.1

Moving (in bulk) to 7.10.4

comment:8 in reply to:  4 Changed 2 years ago by thomie

Milestone: 7.10.17.8.4

deriving/should_compile/T8950 already tests for this.

However, at the very least this should be documented (unless it's easy enough to fix) as a known-bug in 7.8.4's manual (should 7.8.4 be ever be released).

So this ticket can either be closed, or that documentation should be added.

Reverting the milestone back to 7.8.4, since nothing needs to be done for 7.10.1.

comment:9 Changed 2 years ago by thoughtpolice

Resolution: fixed
Status: newclosed

Fixed by marking this in the 7.8.4 manual (see 7fa9d836e3b3e16d3d69a8954cf500dfaa3ea54e).

Note: See TracTickets for help on using tickets.