Improvements to the design of TcReportMsg
!7033 (merged) separates the messages created in GHC.Tc.Errors
into two categories, TcReportMsg
and TcReportInfo
. We then build up a collection of TcReportMsg
s, each of which can be followed by a collection of TcReportInfo
messages. As a result, we end up carrying around some pieces of information manually in the overall SolverReport
(e.g. the sr_hints :: [GhcHint]
field), when it would be more principled for the the hints to be computed in the same way as they are for most other diagnostics.
There are some other improvements possible:
- Rename the datatype to
TcSolverReportMsg
. - Use
TcReportMsg
forTcRnInaccessibleCode
andTcRnRedundantConstraints
. - Be more consistent about when we store fields of type
Ct
in constructors ofTcReportMsg
. It's useful for tooling for these to be available, but it's not very consistent. - Some constructors serve a very similar role, e.g.
Mismatch
vsKindMismatch
vsTypeEqMismatch
. It should be possible to merge these, at the cost of some error message wibbles. - Some constructors of
TcReportInfo
only really make sense for particular constructors ofTcReportMsg
. Can we refactor this to make the dependency clearer? - In some places we end up pretty-printing hints to store in a
TcRnMessageDetailed
, see e.g.GHC.Tc.Gen.Head.tc_infer_id
. Doing away with this might require a refactor ofTcRnMessageWithInfo
.
Additionally, some SDoc
s can still be eliminated:
-
TcRnIllegalBuiltinSyntax
ofTcRnMessage
. -
MissingBinding
andUnknownSubordinate
constructors ofNotInScopeError
.