[Issue 15100] @nogc should ignore allocations on assertion fail

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15100

Jonathan M Davis <issues.dlang at jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang at jmdavisProg.co
                   |                            |m

--- Comment #2 from Jonathan M Davis <issues.dlang at jmdavisProg.com> ---
Whether it even makes sense for new Error to be @nogc depends on whether the GC
is available or not. If it is, then the Error will presumably kill the program,
so the allocation isn't a problem. However, if the GC isn't available, and the
programmer is relying on @nogc to guarantee that the GC isn't actually used,
then there's definitely a problem.

But maybe that can all be cleaned up with the reference counted Object
hierarchy  that's been talked about previously, since Exceptions and Errors
would presumably be part of that - though unless they're malloced, they'd still
be using the GC, and presumably, using new wouldn't use malloc, so if we wanted
a ref-counted Throwable to be on the malloced heap, something other than new
would have to be used.

idup will always use the GC regardless though. I don't see how it could be
otherwise. So, even if it were fixed so that Error was ref-counted and
malloced, idup still wouldn't work without the GC. We really need some other
way to handle the strings for the exception messages if we want to avoid the
GC.

This whole situation is a bit sticky though, because we're basically trying to
ban the GC in @nogc code while still using for stuff related to exceptions, and
that's obviously problematic.

Maybe if allocating for an assertion fails, it should result in a message being
printed (if possible) and then a HLT instruction? Even if Errors in general
have a problem, stuff like assertions are controlled by druntime where we can
have some control over what's going on without requiring a full-blown solution
for dealing with the @nogc problem with exceptions. If we absolutely had to, we
could use a function pointer to a @nogc function and using casting to make it
point to one that isn't actually @nogc, though I really think that we should
find a more principled solution to this that doesn't require lying about being
@nogc.

Regardless of the exact solution here, I suspect that if we want to fully sort
out the various issues with @nogc and exceptions (be they Errors or
Exceptions), we need to sort out the ref-counting Object hierarchy stuff and
whatever that's supposed to do and look like.

--