"fix" segv from #3198, #3199, and #3205

[Skgland]

Fix in quotes as the first two are only converted to panics instead of a full fix.

Issues #3198, #3199 & #3205 are partially fixed/improved.

[Skgland]

Uh, changing the heap_index! macro to use checked multiplication is quite bad (x2) for speed.

[Skgland]

🤦‍♂️ eagerly formatting the error message was the reason for the slow down.
Switching to lazy formatting brings the speed back to about the prior level.

[Skgland]

This should now be ready for review.

[Skgland]

Still ready for review, just with an additional overflow fixed.

[bakaq]

LGTM.

[UWN]

;  E = 64, N = 18446744073709551616, Er = resource_error(finite_memory,18446744073709551616)

Why is the second argument now the size in question? This does not make much sense. Apart from finite_. In particular cumbersome for much larger values.

[UWN]

... that is, why is there a second argument at all? The term should be resource_error(memory).

[Skgland]

;  E = 64, N = 18446744073709551616, Er = resource_error(finite_memory,18446744073709551616)

Why is the second argument now the size in question? This does not make much sense. Apart from finite_. In particular cumbersome for much larger values.

As I said in #3205 (comment)
for larger E this runs into #3201 which I didn't attempt to fix here in this PR.

Basically for E>=64 an allocation in a different code path converting N to usize fails which has a pre-existing bug of emitting the wrong error.

[UWN]

which I didn't attempt to fix here in this PR.

Why not. Without it testing becomes cumbersome.

[Skgland]

which I didn't attempt to fix here in this PR.

Why not. Without it testing becomes cumbersome.

Multiple reasons:

• keep this PR focused and small for easy review
• a bad error is still an improvement over a segmentation fault
• given that this error occurs before we even get to the allocator so we may still have some memory to allocate heap cells it might make sense to turn error(resource_error(finite_memory, B), _) into error(resource_error(memory), [request-elements(B)]) (exact form up for debate/bikeshedding) to preserve more error context, but this requires populate the second argument of error terms thrown from rust with a context list #3173 which is blocked on Lists created in rust using the (.)/2 functor behave weirdly #3171

[UWN]

(exact form up for debate/bikeshedding)

Only error(resource_error(memory),[]) does not entail further problems. In any case, I will have to wait for further testing.

[Skgland]

I think further discussion regarding the resource_error(finite_memory,_) should be moved to #3201 and not be held in this PR.

[Skgland]

@UWN this now includes a fix for the misleading error from #3201.

The change was sufficiently small and while context would be nice (to differentiate "reasonable" amounts of missing memory from architecture exceeding amounts) it is not required.

With that, this is again ready for review.

[UWN]

Solves #3205, #3201 (I read: Changes reviewed No applicable reviews submitted by reviewers with write access.)

[UWN]

I found no problems. This is ready for merging. Thx!