#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 RyanGlScott

Keywords: deriving added

Indeed. The fix for #14579 requires generating code for GeneralizeNewtypeDeriving that has more explicit type/kind signatures. The flipside is that Prim, whose types mention unboxed tuples and levity polymorphic kinds, now requires enabling TypeInType and UnboxedTuples 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 either TypeInType or UnboxedTuples, since those can cause some other programs to break.

Last edited 17 months ago by RyanGlScott (previous) (diff)

comment:2 Changed 17 months ago by fosskers

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 RyanGlScott

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 fosskers

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 RyanGlScott

Differential Rev(s): Phab:D4620
Status: newpatch

comment:6 Changed 17 months ago by fosskers

Thanks!

comment:7 Changed 16 months ago by bgamari

I propose some language to clarify this in the users guide in Phab:D4701.

comment:8 Changed 16 months ago by Ben Gamari <ben@…>

In 0c7db226/ghc:

Fix #15073 by suggesting UnboxedTuples in an error message

Under certain circumstances, `GeneralizedNewtypeDeriving`
can emit code which uses unboxed tuple types, but if `UnboxedTuples`
wasn't enabled, the error message that GHC gave didn't make it very
clear that it could be worked around by explicitly enabling the
extension. Easily fixed.

Test Plan: make test TEST=T15073

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: simonpj, thomie, carter

GHC Trac Issues: #15073

Differential Revision: https://phabricator.haskell.org/D4620

comment:9 Changed 16 months ago by RyanGlScott

Cc: deriving/should_fail/T15073 added
Differential Rev(s): Phab:D4620Phab:D4620, Phab:D4701

comment:10 Changed 16 months ago by Ben Gamari <ben@…>

In b876c1bb/ghc:

users-guide: Point out GNTD may require additional extensions

As noted in #15073, GeneralizedNewtypeDeriving may produce code that
uses extensions that do not directly appear in the code written by the
user.  Make this clear in the users guide.

[skip ci]

Test Plan: Read it

Reviewers: RyanGlScott

Reviewed By: RyanGlScott

Subscribers: fosskers, rwbarton, thomie, carter

GHC Trac Issues: #15073

Differential Revision: https://phabricator.haskell.org/D4701

comment:11 Changed 16 months ago by bgamari

Resolution: fixed
Status: patchclosed
Note: See TracTickets for help on using tickets.