The `producers` section contains meta data of the binary and/or
object file. It *can* contain the source language, the tool it
was processed by, and/or the SDK that was used to produce the file.
For now, we always set the language and processed-by fields to Zig.
In the future we will parse linked object files to detect their
producers sections and append (if different) their language, SDK
and processed-by fields.
Windows requires the directory handle to be closed before attempting to delete the directory, so now we do that and then re-open it if we need to retry (from getting DirNotEmpty when trying to delete).
This was sized large so that `getdents` (and other platforms' equivalents) could provide large amounts of entries per syscall, but some benchmarking seems to indicate that the larger 8192 sizing doesn't actually lead to performance gains outside of edge cases like extremely large amounts of entries within a single directory (e.g. 25,000 files in one directory), and even then the gains are minimal ('./walk-8192 dir-with-tons-of-entries' ran 1.02 ± 0.34 times faster than './walk-1024 dir-with-tons-of-entries').
Note: Sizes 1024 and 2048 had similar performance characteristics, so the smaller of the two was chosen.
`deleteTree` now uses a stack-allocated stack for the first 16 nested directories, and then falls back to the previous implementation (which only keeps 1 directory open at a time) when it runs out of room in its stack. This allows the function to perform as well as a recursive implementation for most use-cases without needing allocation or introducing the possibility of stack overflow.
There are two parts to this:
1. The deleteFile call on the sub_path has been moved outside the loop, since if the first call fails with `IsDir` then it's very likely that all the subsequent calls will do the same. Instead, if the `openIterableDir` call ever hits `NotDir` after the `deleteFile` hit `IsDir`, then we assume that the tree was deleted at some point and can consider the deleteTree a success.
2. Inside the `dir_it.next()` loop, we look at entry.kind and only try doing the relevant (deleteFile/openIterableDir) operation, but always fall back to the other if we get the relevant error (NotDir/IsDir).
Before this commit:
```
$ zig test lib/std/fs/test.zig --main-pkg-path lib/std --zig-lib-dir lib
2170 passed; 37 skipped; 0 failed.
```
After this commit:
```
$ zig test lib/std/fs/test.zig --main-pkg-path lib/std --zig-lib-dir lib
All 45 tests passed.
```
This matches stage1 behavior:
```
$ zig test -fstage1 lib/std/fs/test.zig --main-pkg-path lib/std --zig-lib-dir lib
All 45 tests passed.
```
All tests are still run if `zig test` is run directly on `lib/std/std.zig`:
```
$ zig test lib/std/std.zig --main-pkg-path lib/std --zig-lib-dir lib
2170 passed; 37 skipped; 0 failed.
```
`zig build test-std` is unaffected by this change.
Closes#12926
This was an accidental misuse of the Cache API which intends to call
resolve on all file paths going into it. This one callsite was failing
to do that; fixed now.
Fixes relative file paths from making it into the global cache manifest.
See #13050
This implements the new addition to the API: `sock_accept`.
Reference commit of WASI spec:
0ba0c5e2e37625ca5a6d3e4255a998dfaa3efc52
For full details:
0ba0c5e2e3
For entire spec at this commit:
0ba0c5e2e3/phases/snapshot/docs.md
expected type 'fn() void', found 'fn(i32) void'
function with 0 parameters cannot cast into a function with 0 parameters
=>
expected type 'fn() void', found 'fn(i32) void'
function with 1 parameters cannot cast into a function with 0 parameters
