Apple has already dropped support for macOS 11.
GitHub Actions is dropping macOS 11 support now.
The Zig project is also dropping macOS 11 support now.
This is essentially just a rename. I also changed the representation of
`AnalSubject` to use a `packed struct` rather than a non-exhaustive
enum, but that change is relatively trivial.
This patch is a pure rename plus only changing the file path in
`@import` sites, so it is expected to not create version control
conflicts, even when rebasing.
I renamed std.process.Child.CreateProcessSupportedExtension to WindowsExtension
and made it public to avoid duplicating the list of extensions.
While here, I also improved it to not misreport OOM from std.fs.realpathAlloc()
as a generic failure to find the program, but instead panic like the rest of the
build system does for OOM.
Closes#20314.
In my first [try](https://github.com/ziglang/zig/pull/20224) to fix
20212 I didn't reproduce bug on required kernel (6.9.2) and wrongly
concluded that first two completions have different order on newer
kernel.
On my current kernel (6.5.0) order of completions is: send1, recv,
send2. On 6.9.2 order is send1, send2, recv. This fix allows second two
completions to arrive in any order.
Tested on both kernels.
Fixes: #20212
Stability of std sort was undertested before this change. Add a fuzz
test for more confidence.
Specifically, we used to have a single example test that used an array
of eight elements. That ends up exercising only a tiny fraction of
sorting logic, as it hits a hard-coded sorting network due to small
size.
LLVM fails to notice that in release builds, `logFn` ignores its
arguments, so their computation can be elided. So, LLVM fails to elide
this hashmap lookup. Its cost isn't too significant, but doing it in the
hottest loop in Sema adds up!
Technically, we could do the lookup a single time, before the loop, but
it was cleanest (and a little faster) to just disable this log call at
comptime when debug logging is disabled.
Using std.os.linux directly in e.g. std.posix.timerfd_create() causes
the function to compile but silently fail at runtime when targeting any
OS other than Linux.
To catch errors like this at compile time, std.os.linux must only be
directly accessed within std.posix where there has been a comptime check
that the target os is in fact Linux.
switch from `inline for` with `std.mem.eql`
to `inline else` and tag comparison;
expectEqualDeep(Inner) was already doing this.
add a previously-failing test case.
Since we track `reify` instructions across incremental updates, it is
acceptable to treat it as the baseline for a relative source location.
This turns out to be a good idea, since it makes it easy to define the
source location for a reified type.
I believe this was accidentally broken when the E enum for errno values
was introduces. These functions are quite the special case in that they
return the error value directly rather than returning -1 and passing the
error value through the errno variable.
In any case, using a u16 as the return type at the ABI boundary where a
c_int is expected is asking for trouble.
