No functional changes are expected, this patch is only moving some code
in order to slim the huge bowl of spaghetti that is debug.zig.
The amount of memory leaked on error is much less than before but not
zero, some further work is required to smooth the edges of this old part
of the stdlib.
* fix a merge conflict discovered upon rebasing latest master
* rename Target.Cpu.Feature.Set.subSet to isSuperSetOf
* convert a comment into an assert
If there is a mismatch of CPU features provided
compared to the whitelist, then will fail the build and
print what the expected CPU model is and the feature
set for the model. Also prints what features need to be
removed.
Before this change, when one or more of name or value are not known at
comptime, build.zig files must allocate and do the concatanation, which can be
cumbersome, and also adds a redundant allocation when name and value are
slices. The new version only does a single allocation directly in the builder's
allocator to concatonate name and value.
The origional behavior is available in defineCMacroRaw, for use in situations
such as parseing c compiler arguments.
Additionally, several places have been updated to use the new funtions.
I've added these three functions to all switches except NetBSD, because I don't know what the function is named there. I've even added it on the .windows switch since all the posix functions seem to be there anyways.
It turns out the code was not ported correctly from C and produced wrong
results for negative input values. As a bonus fix the NaN codepath by
adding yet another missing piece of code.
Spotted in #9047
The documentation (e.g. `man 7 rtnetlink`) states that ifi_change "is reserved for future use and should be always set to 0xFFFFFFFF". This is no longer true, even though the text hasn't been updated.
Since v0.23 release of Wasmtime, if we want to iterate a directory
Y then directory Y needed to have been granted `fd_readdir` right.
However, it is now also required for directory X to carry `fd_readdir`
right, and so on, up-chain all the way until we reach the preopen
(which possesses all rights by default).
This caused problems for us since our libstd implementation is more
fine-grained and allowed for parent dirs not to carry the right while
allow for iterating on its children. My proposal here is to always
grant `fd_readdir` right as part of
`std.fs.Dir.OpenDirOptions.access_sub_paths`. This seems to be the
approach taken by Rust also, plus we should be justified to take this
approach since WASI is experimental and snapshot1 will be discontinued
eventually and replaced with a new approach to access management
that will require a complete rewrite of our libstd anyhow.
