compiler/GHC/Builtin/primops.txt.pp

@@ -3692,7 +3692,7 @@ section "Tag to enum stuff"
 primop  DataToTagSmallOp "dataToTagSmall#" GenPrimOp
    a_levpoly -> Int#
    { Used internally to implement @dataToTag#@: Use that function instead!
-     This one offers /no advantage/ and comes with no stability
+     This one normally offers /no advantage/ and comes with no stability
      guarantees: it may change its type, its name, or its behavior
      with /no warning/ between compiler releases.
 

compiler/GHC/Core/Lint.hs

@@ -1131,12 +1131,13 @@ checkTypeDataConOcc what dc
     (text "type data constructor found in a" <+> text what <> colon <+> ppr dc)
 
 {-
--- | Check that a use of dataToTagLarge# satisfies conditions DTT2
+-- | Check that a use of a dataToTag# primop satisfies conditions DTT2
 -- and DTT3 from Note [DataToTag overview] in GHC.Tc.Instance.Class
 --
--- Ignores applications not headed by dataToTagLarge#.
+-- Ignores applications not headed by dataToTag# primops.
 
 -- Commented out because GHC.PrimopWrappers doesn't respect this condition yet.
+-- See wrinkle DTW7 in Note [DataToTag overview].
 checkDataToTagPrimOpTyCon
   :: CoreExpr   -- ^ the function (head of the application) we are checking
   -> [CoreArg]  -- ^ The arguments to the application

compiler/GHC/Tc/Instance/Class.hs

@@ -702,8 +702,7 @@ these conditions:
    GHC.Rename.Module.  See Note [caseRules for dataToTag] in
    GHC.Core.Opt.ConstantFold for why this matters.
 
-   While the dataToTag# primops remain exposed from GHC.Prim
-   (and abused in GHC.PrimopWrappers), this cannot be a true invariant.
+   While wrinkle DTW7 is unresolved, this cannot be a true invariant.
    But with a little effort we can ensure that every primop
    call we generate in a DataToTag instance satisfies this condition.
 
@@ -802,7 +801,7 @@ Wrinkles:
     few enough contructors that the tag always fits in the pointer.
 
   * dataToTagLarge# also consults the tag bits in the pointer, but
-    must fall back te examining the info table whenever those tag
+    must fall back to examining the info table whenever those tag
     bits are equal to mAX_PTR_TAG.
 
   One could imagine having one primop with a small/large tag, or just
@@ -851,7 +850,7 @@ Wrinkles:
     dataToTagLarge# a1 = GHC.Prim.dataToTagLarge# a1
 
   Why do these exist? GHCi uses these symbols for... something.  There
-  is on-going work to get rid of them.  See also #24169 and !6245.
+  is on-going work to get rid of them.  See also #24169, #20155, and !6245.
   Their continued existence makes it difficult to do several nice things:
 
    * As explained in DTW6, the dataToTag# primops are very internal.
@@ -863,7 +862,9 @@ Wrinkles:
      variable `a_levpoly` in the above definitions.  In particular,
      they do not satisfy conditions DTT2 and DTT3 above.  We would
      very much like these conditions to be invariants, but while
-     GHC.PrimopWrappers breaks them we cannot do so.
+     GHC.PrimopWrappers breaks them we cannot do so.  (The code that
+     would check these invariants in Core Lint exists but remains
+     commented out for now.)
 
    * This in turn means that `GHC.Core.Opt.ConstantFold.caseRules`
      must check for condition DTT2 before doing the work described in