This code is adapted from pixelherodev paste from IRC
I have added a new fmt option to handle printing slice values ``{v}`` or ``{V}``
While i think it can be made the default, i want your opinion about it
```zig
var slicea = [0]u32{};
var sliceb = [3]u32{ 1, 2, 3 };
std.log.info("Content: {v}", .{slicea});
std.log.info("Content: {v}", .{sliceb});
```
will print:
```
info: Content: []
info: Content: [1, 2, 3]
```
Question:
Should we drop ``{v}`` and make it the default behavior?
* Improve ArrayList & co documentation
- Added doc comments about the validity of references to elements in
an ArrayList and how they may become invalid after resizing operations.
- This should help users avoid footguns in future.
* Improve ArrayListUnmanaged & co's documentation
- Port improved documentation from ArrayList and ArrayList aligned to
their unmanaged counterparts.
- Made documentation for ArrayListUnmanaged & co more inclusive and
up-to-date.
- Made documentation more consistent with `ArrayList`.
* Corrections on ArrayList documentation.
- Remove incorrect/unpreferred wording on ArrayList vs
ArrayListUnmanaged.
- Fix notes about the alignment of ArrayListAligned
- Be more verbose with warnings on when pointers are invalidated.
- Copy+paste a few warnings
* add warning to replaceRange
* revert changes to append documentation
This commit adds default search paths for system frameworks
on macOS while also adding `-isysroot` for OS versions at least BigSur.
Since BigSur (11.0.1), neither headers nor libs exist in standard
root locations (`/usr/include`, `/System/Library/Frameworks`). Instead, they
are now exclusively part of the installed developer toolchain (either
via XCode.app or CLT), and specifying `-isysroot` allows us to keep
using universal search paths such as `/System/Library/Frameworks` while
only changing the include flag from `-iframework` to
`-iframeworkwithsysroot`.
The current API does not allow the user to distinguish between EOF and
an empty line. Reader.readUntilDelimiterOrEof() gets this API right so
update readUntilDelimiterOrEofAlloc() to match it. Returning an optional
here additionally makes calling this in a loop much cleaner.
Remove readUntilDelimiterOrEofArrayList() as it no longer needed to
implement readUntilDelimiterOrEof() and has the same API issues
described without a clear way to fix them.
* read directly into the ArrayList buffers.
* respect max_output_bytes
* std.ArrayList:
- make `allocatedSlice` public.
- add `unusedCapacitySlice`.
I removed the Windows implementation of this stuff; I am doing a partial
merge of LemonBoy's patch with the understanding that a later patch can
add the Windows implementation after it is vetted.
Keep polling until there are enough open handles, if the child process
terminates closing the handles or explicitly closes them we just quit
polling and wait for the process handle to signal the termination
condition.
Reading stdin&stderr at different times may lead to nasty deadlocks (eg.
when stdout is read before stderr and the child process doesn't write
anything onto stdout).
Implement a polling mechanism to make sure this won't happen: we read
data from stderr/stdout as it becomes ready and then it's copied into an
ArrayList provided by the user, avoiding any kind of blocking read.
These tests asserted there were no args passed to the test binary, but
now there is an arg intentionally passed to the test binary, so the test
case needed to be updated.
