Opened 17 months ago
Closed 16 months ago
#15073 closed bug (fixed)
Unable to newtype derive `Prim` via DerivingStrategies
Reported by: | fosskers | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 8.6.1 |
Component: | Compiler | Version: | 8.2.2 |
Keywords: | deriving | Cc: | deriving/should_fail/T15073 |
Operating System: | Unknown/Multiple | Architecture: | x86_64 (amd64) |
Type of failure: | None/Unknown | Test Case: | |
Blocked By: | Blocking: | ||
Related Tickets: | Differential Rev(s): | Phab:D4620, Phab:D4701 | |
Wiki Page: |
Description
The following compiles with both GHC 8.2.2 and 8.4.1:
newtype Drain = Drain { _drain :: Word8 } deriving stock (Eq, Ord, Show, Generic) deriving newtype (Storable) deriving anyclass (NFData)
However, adding Prim
beside Storable
in the newtype
area yields the following with GHC 8.2.2:
/home/colin/code/haskell/mapalgebra/lib/Geography/MapAlgebra.hs:1148:21-24: error: • Illegal unboxed tuple type as function argument: (# ghc-prim-0.5.1.1:GHC.Prim.State# s1, Word8 #) • In the expression: ghc-prim-0.5.1.1:GHC.Prim.coerce @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep). ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s -> ghc-prim-0.5.1.1:GHC.Prim.Int# -> ghc-prim-0.5.1.1:GHC.Prim.State# s -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Word8) @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep). ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s -> ghc-prim-0.5.1.1:GHC.Prim.Int# -> ghc-prim-0.5.1.1:GHC.Prim.State# s -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Drain) primitive-0.6.3.0:Data.Primitive.Types.readByteArray# In an equation for ‘primitive-0.6.3.0:Data.Primitive.Types.readByteArray#’: primitive-0.6.3.0:Data.Primitive.Types.readByteArray# = ghc-prim-0.5.1.1:GHC.Prim.coerce @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep). ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s -> ghc-prim-0.5.1.1:GHC.Prim.Int# -> ghc-prim-0.5.1.1:GHC.Prim.State# s -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Word8) @(forall (s :: TYPE ghc-prim-0.5.1.1:GHC.Types.LiftedRep). ghc-prim-0.5.1.1:GHC.Prim.MutableByteArray# s -> ghc-prim-0.5.1.1:GHC.Prim.Int# -> ghc-prim-0.5.1.1:GHC.Prim.State# s -> (#,#) ghc-prim-0.5.1.1:GHC.Prim.State# s Drain)
and this with GHC 8.4.1:
Illegal kind: ((:) (ghc-prim-0.5.2.0:GHC.Types.TupleRep ([] :: [] ghc-prim-0.5.2.0:GHC.Types.RuntimeR ep)) ((:) ghc-prim-0.5.2.0:GHC.Types.LiftedRep ([] :: [] ghc-prim-0.5.2.0:GHC.Types.RuntimeRep) :: [] ghc-prim-0.5.2.0:GHC.Types.RuntimeRep) :: [] ghc-prim-0.5.2.0:GHC.Types.RuntimeRep) Did you mean to enable TypeInType? | 1132 | deriving newtype (Storable, Prim) |
Turning on TypeInType
as it suggests gives the same Illegal unboxed tuple...
error.
I've hand-written Storable
instances before so I'm confident in its derivation, but I otherwise know nothing about Prim
. Is there something magical about it that prevents it from being newtype derived in the same way?
Thank you kindly,
Colin
Change History (11)
comment:1 Changed 17 months ago by
Keywords: | deriving added |
---|
comment:2 Changed 17 months ago by
Oh look at that - enabling UnboxedTuples
on my end makes the error disappear, and I seem to be able to use the instance.
comment:3 Changed 17 months ago by
Ah, now I see why you were confused—the Illegal unboxed tuple type as function argument
error message doesn't recommend enabling UnboxedTuples
. Would you consider this issue resolved if the error message were revised to do so?
comment:4 Changed 17 months ago by
I would, yeah. I've never used UnboxedTuples
before (but had heard of them once reminded), so it didn't even occur to me that all I was missing was a LANGUAGE
extension.
comment:5 Changed 17 months ago by
Differential Rev(s): | → Phab:D4620 |
---|---|
Status: | new → patch |
comment:7 Changed 16 months ago by
I propose some language to clarify this in the users guide in Phab:D4701.
comment:9 Changed 16 months ago by
Cc: | deriving/should_fail/T15073 added |
---|---|
Differential Rev(s): | Phab:D4620 → Phab:D4620, Phab:D4701 |
comment:11 Changed 16 months ago by
Resolution: | → fixed |
---|---|
Status: | patch → closed |
Indeed. The fix for #14579 requires generating code for
GeneralizeNewtypeDeriving
that has more explicit type/kind signatures. The flipside is thatPrim
, whose types mention unboxed tuples and levity polymorphic kinds, now requires enablingTypeInType
andUnboxedTuples
to derive, as you've observed.There are a handful of language extensions that GHC always enables under the hood when deriving things (such as
KindSignatures
), but I'm very much doubtful that we'd want to always enable eitherTypeInType
orUnboxedTuples
, since those can cause some other programs to break.