Opened 4 months ago

Last modified 4 months ago

#13530 new bug

Horrible error message due to TypeInType

Reported by: simonpj Owned by:
Priority: normal Milestone:
Component: Compiler Version: 8.0.1
Keywords: TypeInType 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 (last modified by simonpj)

Consider this

{-# LANGUAGE MagicHash, UnboxedTuples #-}

module Foo where

import GHC.Exts

g :: Int -> (# Int#, a #)
g (I# y) = (# y, undefined #)

f :: Int -> (# Int#, Int# #)
f x = g x

With GHC 8 we get

Foo.hs:11:7: error:
    • Couldn't match a lifted type with an unlifted type
      Expected type: (# Int#, Int# #)
        Actual type: (# Int#, Int# #)

What a terrible error message!! It was much better in GHC 7.10:

Foo.hs:11:7:
    Couldn't match kind ‘*’ with ‘#’
    When matching types
      a0 :: *
      Int# :: #
    Expected type: (# Int#, Int# #)
      Actual type: (# Int#, a0 #)

What's going on?

The constraint solver sees

[W] alpha::TYPE LiftedRep  ~  Int#::TYPE IntRep

So it homogenises the kinds, and unifies alpha (this did not happen in GHC 7.10), thus

alpha := Int# |> TYPE co

[W] co :: LiftedRep ~ IntRep

Of course the new constraint fails. But since we have unified alpha, when we print out the types are are unifying they both look like (# Int#, Int# #) (there's a suppressed cast in the second component).

I'm not sure what to do here.

(I tripped over this when debugging #13509.)

Change History (5)

comment:1 Changed 4 months ago by simonpj

Keywords: TypeInType added

comment:2 Changed 4 months ago by goldfire

I think this is #11198.

comment:3 Changed 4 months ago by simonpj

Dead right. We should fix this!

comment:4 Changed 4 months ago by Simon Peyton Jones <simonpj@…>

In bac95f9d/ghc:

Yet another attempt at inferring the right quantification

TcSimplify.decideQuantification is truly a tricky function!
Trac #13509 showed that we were being over-eager with defaulting
of runtime-rep variables (levity polymorphism), which meant that
a program was wrongly rejected, and with a very odd error message
(c.f. Trac #13530)

I spent an unreasonably long time figuring out how to fix this
in a decent way, and ended up with a major refactoring of
decideQuantification, with a kock-on effect in simplifyInfer.

It is at least a bit more comprehensible now; but I still
can't say I like it.

comment:5 Changed 4 months ago by simonpj

Description: modified (diff)
Note: See TracTickets for help on using tickets.