To run test on freestanding target, I have made my custom test_runner.zig based on simple test runner. In order to add memory leak detection report, I want to use DebugAllocator.detectLeaks Zig Documentation But this function log a lot of useful information in the console.
This is indeed very useful for debugging, but freestanding target does not have an Io implementation. My first guess was to cherry-pick this function and remove all Io calls, but it is not possible since it rely on a lot of constant and function that use Io or I can’t access.
My second guess was to pick the entire debug_allocator.zig file and edit it as I want, but the field std.testing.allocator_instance is expecting the std implementation, not my own.
Is there a proper way to overwrite the std.testing.allocator_instance field ?
Disclaimer: I haven’t looked into this too much…
I think that the leak detection ultimately logs using the default logger, which is set in the std.Options instance in the root module (so std_options in your main.zig or other root source file).
Likely you could change the default logger to an implementation that works on your system.
Barring that, given that you are developing for a freestanding target, I’m guessing you know what needs to be done to write your own I/O implementation, so you could do that too 
There is a field for the debug I/O instance in std_options for it to be put as well.
1 Like
I already use a custom log function, but it was some call for random or terminal mode that were annoying.
I wasn’t aware of the debug_io field, it may be a solution. It will try and come back.
For sure as someone that just went through having to deal with build issues on freestanding (making libghostty-vt builds work on wasm32-freestanding during our Zig 0.16.0 update), shaking std.Io.Threaded entirely out of the tree proved to be somewhat tricky.
Ultimately we used std.Io.failing to get rid of the issues, but it sounds like you may need some functionality that may be covered by actual I/O (although if it was just RNG and you already have a different logging implementation then maybe not so much).