Remove aBSENT_(SUM_)ERROR_ID, come up with better boxed rubbish value instead
In !5145 (comment 341693), I got aware of Note [aBSENT_ERROR_ID]
, esp. the intricacies regarding stable unfoldings which make it necessary to drop seq
s on expressions that force absent errors.
#19133 (closed) and the long discussion in !5145 (closed) made increasingly clear to me that it might be worthwhile to get rid of absent errors altogether and always use boxed rubbish values instead.
What are the drawbacks? As Note [Absent fillers] of !5145 (closed) explains, it's a huge decrease in compiler dev debugging experience should an absent filler be relevant in the program after all (like it was in #11126 (closed) or #14285 (closed)). Today, we'd get a nice panic message immediately upon evaluation. If we pick a rubbish value (which amounts to pointing to the ()
constructor for boxed types at the moment), we might not even get a panic and keep on executing the program with malformed inputs, see Modes of failure in Note [Rubbish values] (in !5145 (closed)).
So the feasibility of removing absent errors crucially depends on finding a better boxed rubbish value.
How about we simply have a pointer to an unallocated memory page and tag it properly (e.g. 1), so that a seq
will never enter it? Heck, we could even literally use the pointer 1
, which is (char*)NULL+1
for a very low-tech solution. Then we already would've gained much: Unlike the hacks described in Note [aBSENT_ERROR_ID]
, rubbish values are actually evaluated and will be treated as such in Core. And even if we seq
such a rubbish value (something that #16970 (closed)/!1472 (closed) is interested in doing), there is no harm because the pointer is already tagged and the seq will finish immediately. We would panic as prompt as with the current absent error mechanism (which is the most important gain) and not propagate the error possibly infinitely, only the error message would suffer. But the error message of absent errors is almost worthless in more complex settings anyway, as #11126 (closed) showed. This was the panic message:
Main: Oops! Entered absent arg arr2 Array D DIM1 Double
I believe the ticket was open and unresolved for so long because it's impossible to act on this message, given there are about 20 libraries imported and what not. We only fixed it "by accident", by fixing #18638 (closed). I don't think we would have ever made progress on #11126 (closed) without the smaller reproducer from #18638 (closed). In fact, we aren't sure whether #11126 (closed) is fixed to this day, simply because it's hard to reproduce.
Granted, the panic message is hugely improved these days, because it includes the file name of the absent error. A more high-tech solution would be to point to one memory page per occurrence of boxed rubbish value, then we can even install an exception handler that translates the address of the faulted memory page back to the occurrence of the rubbish value, should code access it.
Here are a list of tickets that I think would be affected beneficially by this change (feel free to add):