Open sauclovian-g opened 1 month ago
Also, there should be a framework for status reporting (in the sense of: we are running, what are we doing, what progress are we making) which is both part of this (since it's about printing) but quite distinct from errors and warnings.
(Plus there should be support for selective dumping of internal representations, and support for logging and tracing, all of which are also related but quite distinct in nature.)
These additional printing topics didn't make it into the original description because (a) they're optional in a way that error reporting isn't, and (b) we don't have much in the way of such infrastructure or such printing currently so the need isn't as immediate. However, review of the situation has made it clear that to the extent we don't have these things, that's a problem and we should.
Re logging in particular there's a long-standing request for that in #870.
Right now errors are printed and ensuing aborts taken through an incredible variety of functions, some of which print, some of which throw things meant to be printed, some of which apparently do both, some of which allow position reporting (others don't). There's also a whole second variety of functions for random prints that don't directly cause failure. This should all get systematized; we ought to have one function for panics and a small number more for messages of various types and severities, all defined in one place, and everything should use only those functions.
This offers a whole range of benefits, not limited to:
Interconnected with #2128. Also more or less a prerequisite for #2075.