If an assert error allocates memory, the GC allocation code can't use assert, because it enters in an infinite recursion if the assertion fail. Since OutOfMemory don't allocate, I think a similar trick can be done for assert. Is not too bad the current situation, because it only affects the GC, but it would be nice to be able to use assert inside the GC without having to be very careful that the assert is not used in the code path for allocation (which includes the collection itself).
This is a bit comical, because the GC (gcx.d) already uses lots of asserts. They are just disabled, because Phobos is compiled in release mode.
(In reply to comment #1) > This is a bit comical, because the GC (gcx.d) already uses lots of asserts. > They are just disabled, because Phobos is compiled in release mode. The good (?) news is the program still aborts when the assert fails, but because of a segmentation fault for stack exhaustion :) Asking GDB for a backtrace is not fun at all =P
I think, GC should just use special kind of assert.
(In reply to comment #3) > I think, GC should just use special kind of assert. Why? And how is desirable that an assert allocates? I agree that the GC *could* use a special kind of assert, as I said it's really not that bad, but I don't see how it *should*. The GC have to do a lot of special casing already if it's written in D, how adding more special cases for the GC developers is good?
An embarrassment of riches. https://github.com/dlang/druntime/pull/1714 https://github.com/dlang/druntime/pull/1710
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17228 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB