Don't burn RecTcChecker fuel for non-recursive TyCon's
Motivation
#18349 discusses improvements to findTypeShape
, specifically to increase its precision: It aborts too early for non-recursive record types. That's why it has an awkward special case for tuples.
That special case should rather live inside checkRecTc
, so that other use sites handle tuples better (remember: we can't run into an infinite loop just by unwrapping tuples; there always is a recursive data or newtype involved).
Proposal
Don't track non-recursive TyCons in RecTcChecker
at all! Of course, for that we need to know which TyCons are surely non-recursive.
So a sub-task here is to write an analysis that flags TyCons which are surely non-recursive. I imagine the typical SCC analysis stuff I hand-waved about here, plus a mechanism that conservatively tags all TyCons as recursive if we import them from .hs-boot files.
Incidentally, we used to have an analysis just like that, plus a predicate isRecursiveTyCon
, until b8b3e30a. There we deleted it on the grounds that .hs-boot files are tricky (I argue above to just be conservative and flag them as recursive) and that data T f a = MkT (f a)
can be made "recursive" by instantiating it with a recursive f
, but then really f
is recursive and not T
, and we'll see that when unwrapping MkT
's field. Granted; there is an f
for which T f a
has infinitely many values, but that's not what "T
is recursive" means to me.
Until we have the more sophisticated analysis, we can keep on writing a function isSurelyNonRecursiveTyCon
which responds with True to tuple tycons, for example, and other cases where it's plain obvious (like when all field have are polymorphic fields like Left a
). That's a meaningful middle-ground as it puts findTypeShape
on a more principled, although still hack-ish, basis.