* Add an assert-based segfault handler to `etc.linux.memoryerror`
* Commit memoryAssertError review feedback
* Indent the MemoryErrorSupported version block
* Fix a bad ucontext_t in memoryerror.d
* Fix bad imports in memoryerror.d
* Use a module-scope version: in memoryerror.d
* Add a memoryerror.d unittest
* Prefer version-else-version... in memoryerror.d
* Fix build on i686, arm64 and x86_64+32b multilib for Darwin.
osthread.d needs to import the thread state definitions for each
supported arch (but was only importing x86_64).
NOTE1: Iain Buclaw pointed out that the ucontext import was unused
and do I have removed that too.
NOTE2: I did not add the data for 32bit Arm (as distinct from the
possible use of AArch64/ILP32), because there is no way I know
to test that - since there's no upstream 32b Arm implementation.
NOTE3: The earlier Darwin versions (equivalent to MacOSX 10.5) have
quite limited D support - but both i686 and PowerPC should be able
(at least) to build the druntime.
I tested on x86_64,i686-Darwin17 and aarch64-darwin23.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
* Address code reviews.
---------
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
Co-authored-by: Iain Buclaw <ibuclaw@gdcproject.org>
For both GCC and LLVM, `__builtin_expect` and `llvm_expect` respectively
return an integer, not a boolean. This triggers a compiler error as
implicit narrow conversions are not allowed.
* Move array functions into conservative GC.
* Move array functions into conservative GC. Implement stubs for manual GC
and proto GC.
* Add note about trusted functions
hasIndirections doesn't handle static arrays of length 0 correctly (they
don't actually have any indirections), because operator precedence
resulted in the check for 0 length static arrays having no actual
effect.
I also copied the test for
https://issues.dlang.org/show_bug.cgi?id=12000 from std.traits to here,
because it's really a compiler bug that's being tested rather than
hasIndirections itself (so being in the compiler repo arguably makes
more sense), and it also arguably makes more sense to put it next to the
actual implementation than in std.traits where it's been.
