I believe the reason we had that check in the first place was because for both `pthread_setname_np` and `pthread_getname_np` man says:
```
CONFORMING TO
These functions are nonstandard GNU extensions; hence the suffix "_np" (nonportable) in the names.
```
However, this `is_gnu` check was never consistently applied; it was
missing in `setName` in the Linux case. It is also missing on all other call sites for other platforms (macOS, iOS, et al.).
Though, that could be because it may only apply to Linux.
I think for a best-effort approach it is okay to drop this. It's probably less non-standard than man makes it out to be.
I noticed a comment saying that the intent of a code's author was unclear.
What happened is that the author forgot to put the check for whether the
thread is the calling thread (`self.getHandle() ==
std.c.pthread_self()`) in the `if (use_pthreads)`.
If the thread is the calling thread, we use `prctl` to set or get the
thread's name and it does not take a thread id because it knows the id
of the thread we're calling `getName` or `setName` from.
I have found a source saying that using `pthread_setname_np` on either the calling thread
or any other thread by thread id would work too (so we don't need to
call `prctl`) but I was not sure if that is the case on all systems
so we keep using `pthread_setname_np` if we have a
specific thread that is not the thread we're calling from, and `prctl`
otherwise.
Forcing the key to be of the same type as the sorted items used during
the search is a valid use case.
There, however, exists some cases where the key and the items are of
heterogeneous types, like searching for a code point in ordered ranges
of code points:
```zig
const CodePoint = u21;
const CodePointRange = [2]CodePoint;
const valid_ranges = &[_]CodePointRange{
// an ordered array of ranges
};
fn orderCodePointAndRange(
context: void,
code_point: CodePoint,
range: CodePointRange
) std.math.Order {
_ = context;
if (code_point < range[0]) {
return .lt;
}
if (code_point > range[1]) {
return .gt;
}
return .eq;
}
fn isValidCodePoint(code_point: CodePoint) bool {
return std.sort.binarySearch(
CodePointRange,
code_point,
valid_ranges,
void,
orderCodePointAndRange
) != null;
}
```
It is so expected that `std.sort.binarySearch` should therefore support
both homogeneous and heterogeneous keys.
This requires manual defines before C99 which may not have stdint.h.
Also have update-zig1 leave a copy of lib/zig.h in stage1/zig.h, which
allows lib/zig.h to be updated without needing to update zig1.wasm.
Note that since the object already existed with the exact same contents,
this completely avoids repo bloat due to zig.h changes.
- Fix assertion failure if AstGen failed on a multi-module file
- Cap number of per-error reference notes and total multi-module errors each at 5
- Always put "root of package" reference notes first
Resolves: #14499
lld accepts both syntaxes, but we were rejecting (and, before
3f7e9ff597a3514bb1c4f1900027c40682ac9f13, ignoring) the former.
In particular, "cargo-zigbuild" was broken since Rust
unconditionally adds "-znoexecstack" (not "-z noexecstack")
on non-Windows platforms.
Co-authored-by: Andrew Kelley <andrew@ziglang.org>
