Dead suggestion for -XUnliftedNewtypes in checkNewDataCon
Note [Implementation of UnliftedNewtypes], point says:
<Error Messages>: It's tempting to think that the expected kind for a newtype constructor argument when -XUnliftedNewtypes is *not* enabled should just be Type. But this leads to difficulty in suggesting to enable UnliftedNewtypes. Here is an example: newtype A = MkA Int# If we expect the argument to MkA to have kind Type, then we get a kind-mismatch error. The problem is that there is no way to connect this mismatch error to -XUnliftedNewtypes, and suggest enabling the extension. So, instead, we allow the A to type-check, but then find the problem when doing validity checking (and where we get make a suitable error message).
I think that Note refers to the code in
GHC.Tc.TyCl.checkNewDataCon (which is transitively called from
checkValidTyCon). There we have
; unlifted_newtypes <- xoptM LangExt.UnliftedNewtypes ; let allowedArgType = unlifted_newtypes || isLiftedType_maybe (scaledThing arg_ty1) == Just True ; checkTc allowedArgType $ vcat [ text "A newtype cannot have an unlifted argument type" , text "Perhaps you intended to use UnliftedNewtypes" ]
But that error emssage doesn't occur anywhere in the testsuite. If you try the example
A from the Note, you instead get
test.hs:20:1: error: • Newtype has non-* return kind ‘TYPE 'IntRep’ Perhaps you intended to use UnliftedNewtypes • In the newtype declaration for ‘A’ | 20 | newtype A = MkA Int# | ^^^^^^^^^^^^^^^^^^^^
(Side note: It's a bit surprising that the emission of that error suppresses any following errors, for example of a following decl
newtype B = MkB Int#. Perhaps this has to do with the next paragraph.)
That message (which I actually prefer) is emitted by
It seems we can just get rid of the code in
checkNewDataCon. Either way, we should update Note [Implementation of UnliftedNewtypes]. Maybe Split if off into its own Sub-Note? That Note is awfully long and has many many sub items.