How to suppress errors from type inference rules.

In our language, we report well-known type errors using checking rules. These rules more or less guarantee that we have access to concrete nodes, allowing us to correctly report errors on them.

We also have some inference rules that end up operating on purely transient nodes (i.e. type nodes that were generated by typesystem evaluation). These sometimes result in errors (due to failed inference), which is expected, but we aren't able to report them properly:  in some cases they reference incomplete types, and we don't know the concrete source node of the error.

Knowing that we can (for the most part) detect and report the same errors from checking rules, is there a way to suppress the error messages from these inference rules?

3 comments
Comment actions Permalink

Unfortunately, no, there is no way to suppress errors reported internally by the typechecker. However, you have full control over error reporting from the inference rules, since they are produced by "report error" statements. 

0
Comment actions Permalink

Thanks for the response!

As far as having control of error reporting from inference rules - as I mentioned, there are some cases where the error ends up being reported on purely transient nodes. These don't (and shouldn't) carry any information about where they originated, thus it's not possible to report errors from these nodes.

Additionally, there are nodes where inference rules are done on non-concrete types. The errors that are automatically reported by these nodes have incomplete type names (i.e. a4 or p2) corresponding to their typevars. In this case, we can use a `when concrete` block to report errors when the types have been established, but this leads to another issue: two errors, once with valid type names, once with typevar names (or with a default error message)

Lastly, having errors reported from the inference rules is relatively inflexible. Inference rules *always* report an error when they fail, and their error message is internal to the rule, whereas with checking rules we have the ability to factor out common error cases, not to mention the ability to create unique checking rules for different error cases.

0
Comment actions Permalink

I agree that the typechecker behaviour with respect to error reporting is not ideal, and really can't suggest any solution that could serve as a workaround. You may want to create an issue in the tracker, but I should also mention that the typechecker code is now very seldom maintained, as we don't have enough time for it. 

0

Please sign in to leave a comment.