Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#11723 closed bug (fixed)

TYPE 'UnboxedTupleRep is a lie

Reported by: goldfire Owned by: goldfire
Priority: highest Milestone: 8.0.1
Component: Compiler Version: 8.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash Test Case: typecheck/should_fail/T11723
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


From @RyanGlScott, comment:28:ticket:11471:

I notice that there's a single constructor of RuntimeRep for unboxed tuples (UnboxedTupleRep). Does this mean something like this should be allowed?

{-# LANGUAGE DataKinds #-}
{-# LANGUAGE KindSignatures #-}
module Example where

import Data.Typeable
import GHC.Exts

data Wat (a :: TYPE 'UnboxedTupleRep) = Wat a

Currently, that fails to compile due to a separate GHC panic:

$ /opt/ghc/head/bin/ghc -O2 -fforce-recomp Example.hs
[1 of 1] Compiling Example          ( Example.hs, Example.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 8.1.20160317 for x86_64-unknown-linux):
        unboxed tuple PrimRep

Please report this as a GHC bug:

But wouldn't this be dangerous anyway? After all, unboxed tuples are supposed to represent arguments on the stack, so couldn't unboxed tuple polymorphic potentially lead to the RTS miscalculating how much data to read? Or am I misreading this?

Change History (9)

comment:1 Changed 4 years ago by goldfire

You're absolutely right. Not only can we not have representation-polymorphic things, we can't have things -- other than plain unboxed tuples -- that have UnboxedTupleRep. Thanks for poking on this. Fix to come shortly.

comment:2 Changed 4 years ago by RyanGlScott

Would it be sensible to just change the constructor to:

data RuntimeRep
  = ...
  | UnboxedTupleRep [RuntimeRep]

Or if we want to avoid conflating VoidRep and UnboxedTupleRep [], we could use UnboxedtupleRep (NonEmpty RuntimeRep)?

That way,

typeOf (Proxy :: Proxy (# Int, Int #))

would give

Proxy (TYPE ('UnboxedTupleRep '[PtrRepLifted, PtrRepLifted])) (# Int, Int #)

and thus have unambiguous size?

Last edited 4 years ago by RyanGlScott (previous) (diff)

comment:3 Changed 4 years ago by goldfire

I thought of that. But GHC's current story around PrimReps -- which is what the code generator uses -- keeps unboxed tuples entirely separate. So I think it's best to echo that here, too. Perhaps we can revisit this later.

comment:4 Changed 4 years ago by simonpj

Owner: set to goldfire

Sounds as though Richard is already working on a fix.

comment:5 Changed 4 years ago by simonpj

Priority: highhighest

I'm going to make this 'highest' because Richard's fix sounds imminent.

If not, is it a release blocker?

comment:6 Changed 4 years ago by goldfire

Imminent Imminent Yes Yes.

Validating (again) right this very moment.

comment:7 Changed 4 years ago by Richard Eisenberg <eir@…>

In d978c5e/ghc:

Fix #11723 and #11724.

Test cases: typecheck/should_fail/T1172{3,4}

comment:8 Changed 4 years ago by goldfire

Status: newmerge
Test Case: typecheck/should_fail/T11723

comment:9 Changed 4 years ago by bgamari

Resolution: fixed
Status: mergeclosed
Type of failure: None/UnknownCompile-time crash
Last edited 4 years ago by bgamari (previous) (diff)
Note: See TracTickets for help on using tickets.