Two mistakes I made when translating from the C header:
- The timeout and userspace_address2 pointers should be nullable.
- futex_wait() and futex_wake() are defined as static functions and
therefore not available as exported symbols. They're just thin
wrappers around futex() anyway so that's fine.
I'd have preferred if `vtable.futexWait` returned `error.Timeout`, since
all the OS-level APIs provide it. However, if I keep the vtable untouched,
I had to determine the timeout case by post-checking the deadline.
It's fine functionally, but one extra syscall that be avoided at
cost of changing the vtable and all the futex implementations.
@SizeOf(@typeInfo(T)) for any u{n} seems to give sizes of u32, u64, u128
and so on, depending on what size x fits into. This causes problems with
'>>' if x isn't exactly one of those sizes.
@typeInfo(@TypeOf(x)).int.bits gives a more accurate size.
This required a thorough audit of every syscall wrapper in std.os.linux, so
while I was here, I fixed some minor arch-specific bugs, improved some types,
simplified some casts, and deleted some dead code.
Note that lseek() in particular is still broken for n32 and x32 after this
commit; this wrapper will require some special-casing in the arch bits due to
its unusual return type width.
closes https://github.com/ziglang/zig/issues/22464
closes https://codeberg.org/ziglang/zig/issues/31597
For some of these functions and most targets this changes nothing,
either because long double and double are not equivalent or because
llvm did function deduplication.
But e.g. on aarch64-windows-gnu, ucrt provides hypot, but not hypotl.
Now hypotl calls hypot from ucrt instead of including the std.math.hypot
implementation in zigc.
Very trivial functions (like nanl) are not changed, because a function call would probably make this function more complex.
...but not in the way you'd expect. We were actually tracking them in
cases where we shouldn't have been! We cannot track a declaration if its
parent namespace has been lost, because that will cause analysis
failures immediately, but if we excluded a type from the mapping due to
a major change (such as a struct turning into a union, or a field being
added), we were still including any trackable instructions inside the
container's field expressions (e.g. struct field type expressions). This
meant we were tracking a type declaration while losing tracking on its
parent namespace, with predictably disastrous results.
Oh, also, tracking for opaque types was just totally wrong (I think this
was a typo from a while back). We could map it to things other than
opaque declarations, and we never mapped declarations inside opaques.
So, uh, I fixed that too.
Justus Klausecker