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 GHC.Tc.Gen.HsType.checkDataKindSig
.
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.