Before, selfExePath would be the path of the symlink on Windows instead of the path of what the symlink points to.
This deprecates fs.selfExePathW since it does not provide a separate use-case over selfExePath (before, the W version could return [:0]u16 directly)
Fixes#16670
This matches how other filesystem functions were made to handle BAD_NETWORK_PATH/BAD_NETWORK_NAME in https://github.com/ziglang/zig/pull/16568. ReadLink was the odd one out, but that is no longer the case.
In theory, localhost could be mapped to a different address via the LMHOSTS file, so using 127.0.0.1 should remove that potential wrinkle and allow the drive-absolute -> UNC transformation to work on any(?) setup.
Also print the error name to ensure it gets printed in CI (aarch64-windows ReleaseSmall seemed not to print the error in the last intermittent UNC failure)
* Generalise NaN handling and make std.math.nan() give quiet NaNs
* Address uses of std.math.qnan_* and std.math.nan_* consts
* Comment out failing test due to issues with signalling NaN
* Fix issue in c_builtins.zig where we need qnan_u32
Prior to this change, we would unconditionally emit any system include path/framework
path as `-iwithsysroot`/`-iframeworkwithsysroot` if the sysroot was
set which can lead to unexpected build failures. Now, calls to
`b.addSystemIncludePath` and `b.addFrameworkPath` will always emit
search paths as `-isystem`/`-iframework`. As a result, it is now up to
the user to correctly concat the search paths with the sysroot when
and where desired.
If there is a need for emitting `-iwithsysroot`/`-iframeworkwithsysroot`
I would advise adding explicit hooks such as `addSystemIncludePathWithSysroot`
and `addFrameworkPathWithSysroot`.
Closes#16861
Using `alloc_if_needed` when parsing a `Value` allows receiving a token
which points to the buffer of the underlying `Reader`. This token will
no longer be valid after the `Reader`'s buffer is refilled, which will
happen with large values. Using `alloc_always` avoids this issue by
ensuring the returned tokens always own their data independently of the
underlying buffer.
When using `std.Build.dependency` with target options, dependencies
would sometimes get targets which are equivalent but have distinct
names, e.g. `native` vs `native-native`. This is a somewhat broad issue,
and it's unclear how to fix it more generally - perhaps we should
special-case CrossTarget in options passing, or maybe targets should
have a canonical name which we guarantee to use everywhere aside from
raw user input.
However, this commit fixes the most egregious issue, which was an active
blocker to using the package manager for some users. This was caused by
the CPU changing from `native` to a specific descriptor (e.g.
`skylake+sgx`), which then changed the behavior of `zigTriple`.
Resolves: #16856
This fixes a few things:
- Previously, CreateSymbolicLink would always create a relative link if a `dir` was provided, but the relative-ness of a link should be determined by the target path, not the null-ness of the `dir`.
- Special handling is now done to symlink to 'rooted' paths correctly (they are treated as a relative link, which is different than how the xToPrefixedFileW functions treat them)
- ReadLink now correctly supports UNC paths via a new `ntToWin32Namespace` function which intends to be an analog of `RtlNtPathNameToDosPathName` (RtlNtPathNameToDosPathName is not used because it seems to heap allocate as it takes an RTL_UNICODE_STRING_BUFFER)
Commit ea9917d9bd921f9fc14028a8dbf9e3f0f2579120 introduced usage
of fs.Dir.realpath which eventually calls os.getFdpath which is
forbidden to be used by the compiler. It causes building zig to fail on
OpenBsd, NetBSD and older versions of FreeBSD and DragonFly.
This patch substitutes with os.realpath on libc targets and eventually
calls c.realpath and allows zig to build. Any use of realpath is not
desired but this is the lesser evil.
We do not yet have correct implementation to access xmm registers from
the world of ucontext/mcontext.
Unimplement .netbsd to allow building zig compiler.
* std.unicode: Add more UTF-16 decoding functions
This mostly makes parts of Utf16LeIterator reusable
* std.json: Fix decoding of UTF-16 surrogate pairs
Before this commit, there were 524,288 codepoints that would get decoded improperly. After this commit, there are 0.
Fixes#16828
* Consistent decryption tail for all AEADs
* Remove outdated note
This was previously copied here from another function. There used
to be another comment on the tag verification linking to issue #1776,
but that one was not copied over. As it stands, this note seems fairly
misleading/irrelevant.
* Prettier docs
* Add note about plaintext contents to docs
* Capitalization
* Fixup missing XChaChaPoly docs
Previously, a relative path like `..` would:
- Attempt to be normalized (i.e. remove . and .. without any path resolution), but would error with TooManyParentDirs
- This would make wToPrefixedFileW run it through `RtlGetFullPathName_U` to do the necessary path resolution, but `RtlGetFullPathName_U` always resolves relative paths relative to the CWD
Instead, when TooManyParentDirs occurs, we now look up the path of the passed in `dir` (if it's non-null) and append the relative path to it before giving it to `RtlGetFullPathName_U`. If `dir` is null, then we just give it RtlGetFullPathName_U directly and let it resolve it relative to the CWD.
Closes#16779
