<div dir="ltr"><div>Hi Olaf,</div><div><br></div><div>I don't know the precise background to the current system for assignment of error codes, but I do know that there is ongoing work to provide more structure to errors. These instances of overly-general codes (and hypothetically some that may be overly-specific) are artifacts of a rather young process.</div><div><br></div><div>I added some of your suggestions to the ticket.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 2 Jun 2023 at 17:16, Olaf Klinke <<a href="mailto:olf@aatal-apotheke.de">olf@aatal-apotheke.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Hm, yikes, I tend to agree this is a very general error message. Here<br>
> are<br>
> all the places "83865" shows up in the code base:<br>
> <br>
>  <br>
> <a href="https://gitlab.haskell.org/search?search=83865&project_id=1&group_id=2&search_code=true&repository_ref=master" rel="noreferrer" target="_blank">https://gitlab.haskell.org/search?search=83865&project_id=1&group_id=2&search_code=true&repository_ref=master</a><br>
> <br>
> I opened <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/23466" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/issues/23466</a> to follow<br>
> up.<br>
> Feel free to weigh in. (Contact me if you need an account - spam<br>
> measures<br>
> currently include manual approvals for new accounts.)<br>
> <br>
<br>
Thanks, Bryan. <br>
<br>
This made me wonder what the current system behind assignment of error<br>
codes is. I'd expect five-digit error codes to be *more* specific than<br>
the general shape of error message emitted by ghc, but here it is<br>
evidently less specific. 82865 stands for the error message constructor<br>
TypeEqMismatch [1] which is a record [2] with many fields. In<br>
particular, the teq_mismatch_expected and teq_mismatch_actual fields<br>
hold structural information: a ForAllTy [3] may hint at simplified<br>
subsumption. <br>
<br>
Thus my proposal would be that error codes are composite values, with<br>
one part (as currently implemented) in bijection to the error message<br>
constructor and another part determined by a function of the actual<br>
error value. This function has to be chosen to provide sufficient<br>
abstraction from the actual situation but e.g. differentiate between<br>
constructors of the Type type. For example, why don't the cases<br>
differentiated by the pretty-printer [4] not own their own error codes?<br>
<br>
Olaf<br>
<br>
[1] <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Types/Error/Codes.hs" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Types/Error/Codes.hs</a><br>
[2] <a href="https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Tc.Errors.Types.html#TypeEqMismatch" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Tc.Errors.Types.html#TypeEqMismatch</a><br>
[3] <a href="https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Core.TyCo.Rep.html#ForAllTy" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Core.TyCo.Rep.html#ForAllTy</a><br>
[4] <a href="https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Tc.Errors.Ppr.html#pprMismatchMsg" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/ghc-9.6.1/docs/src/GHC.Tc.Errors.Ppr.html#pprMismatchMsg</a><br>
<br>
</blockquote></div>