and increase kernel backlog to the maximum number. Without increasing
the kernel backlog to the maximum number, I observed connect() to block
indefinitely, even when another thread calls shutdown() on that socket
file descriptor.
std.Thread.Pool: back to spawning all threads in initialization because
it's overall simpler. This scheme requires init to be passed a pointer
to the struct.
std.process.Child: implement integration with thread pool jobserver. The
environment variable is called `JOBSERVERV2`. The API works based on
assigning a thread pool to the child process.
build runner: store the thread pool in std.Build.Graph so that it can be
passed to child processes during the make phase.
Fix not allocating +1 pollfds in previous commit.
The host accepts N simultaneous connections and writes 1 byte to them
each. Clients connect and read 1 byte in order to obtain a thread token.
std.Thread.Pool now lazily spawns threads only when the work queue is
non-empty. I think that was a bad idea and will revert it shortly.
There is now a std.zig.initThreadPool wrapper that deals with:
* Resolving a zig cache directory into a UNIX domain socket address.
* Creating the "tmp" directory in .zig-cache but only if the listen
failed due to ENOENT.
* Deciding to connect to an existing jobserver, or become the host for
child processes.
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.
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.
Now there is `captureChildProcess` which gives access to the
`std.process.Child.RunResult`, which is useful for accessing the stdout.
It also accepts and passes an optional `std.Progress.Node` to the child.
There were two primary issues at play here:
1. The hex float prefix was not handled correctly when the stream was
reset for the fallback parsing path, which occured when the mantissa was
longer max mantissa digits.
2. The implied exponent was not adjusted for hex-floats in this branch.
Additionally, some of the float parsing routines have been condensed, making
use of comptime.
closes#20275
🦀 src_decl is gone 🦀
This commit eliminates the `src_decl` field from `Sema.Block`. This
change goes further to eliminating unnecessary responsibilities of
`Decl` in preparation for its major upcoming refactor.
The two main remaining reponsibilities had to do with namespace types:
`src_decl` was used to determine their line number and their name. The
former use case is solved by storing the line number alongside type
declarations (and reifications) in ZIR; this is actually more correct,
since previously the line number assigned to the type was really the
line number of the source declaration it was syntactically contained
within, which does not necessarily line up. Consequently, this change
makes debug info for namespace types more correct, although I am not
sure how debuggers actually utilize this line number, if at all. Naming
types was solved by a new field on `Block`, called `type_name_ctx`. In a
sense, it represents the "namespace" we are currently within, including
comptime function calls etc. We might want to revisit this in future,
since the type naming rules seem to be a bit hand-wavey right now.
As far as I can tell, there isn't any more preliminary work needed for
me to start work on the behemoth task of splitting `Zcu.Decl` into the
new `Nav` (Named Addressable Value) and `Cau` (Comptime Analysis Unit)
types. This will be a sweeping change, impacting essentially every part
of the pipeline after `AstGen`.
This is in preparation for some upcoming changes to how we represent
source locations in the compiler. The bulk of the change here is dealing
with the removal of `src()` methods from `Zir` types.
The justification for using relative source nodes in ZIR is that it
allows source locations -- which may be serialized across incremental
updates -- to be relative to the source location of their containing
declaration. However, having those "baseline" instructions themselves be
relative to their own parent is counterproductive, since the source
location updating problem is only being moved to `Decl`. Storing the
absolute node here instead makes more sense, since it allows for this
source location update logic to be elided entirely in the future by
storing a `TrackedInst.Index` to resolve a source location relative to
rather than a `Decl.Index`.
Before this commit, the DIRECTORY_NOT_EMPTY/FILE_IS_A_DIRECTORY/NOT_A_DIRECTORY statuses were assumed only to be possible when using `FILE_RENAME_INFORMATION_EX` and `FILE_RENAME_POSIX_SEMANTICS`, but that has empirically been shown to be false; a networked samba share can return the DIRECTORY_NOT_EMPTY status from `FILE_RENAME_INFORMATION` (which doesn't support `FILE_RENAME_POSIX_SEMANTICS`).
`FILE_IS_A_DIRECTORY` and `NOT_A_DIRECTORY` were not proven to be possible, but they were also moved to the outer switch just in case.
Fixes#19785
Deprecated aliases that are now compile errors:
- `std.fs.MAX_PATH_BYTES` (renamed to `std.fs.max_path_bytes`)
- `std.mem.tokenize` (split into `tokenizeAny`, `tokenizeSequence`, `tokenizeScalar`)
- `std.mem.split` (split into `splitSequence`, `splitAny`, `splitScalar`)
- `std.mem.splitBackwards` (split into `splitBackwardsSequence`, `splitBackwardsAny`, `splitBackwardsScalar`)
- `std.unicode`
+ `utf16leToUtf8Alloc`, `utf16leToUtf8AllocZ`, `utf16leToUtf8`, `fmtUtf16le` (all renamed to have capitalized `Le`)
+ `utf8ToUtf16LeWithNull` (renamed to `utf8ToUtf16LeAllocZ`)
- `std.zig.CrossTarget` (moved to `std.Target.Query`)
Deprecated `lib/std/std.zig` decls were deleted instead of made a `@compileError` because the `refAllDecls` in the test block would trigger the `@compileError`. The deleted top-level `std` namespaces are:
- `std.rand` (renamed to `std.Random`)
- `std.TailQueue` (renamed to `std.DoublyLinkedList`)
- `std.ChildProcess` (renamed/moved to `std.process.Child`)
This is not exhaustive. Deprecated aliases that I didn't touch:
+ `std.io.*`
+ `std.Build.*`
+ `std.builtin.Mode`
+ `std.zig.c_translation.CIntLiteralRadix`
+ anything in `src/`
The doc comments for this global said:
"Locked to avoid interleaving panic messages from multiple threads."
Huh? There's already a mutex for that, it's the stderr mutex. Lock that
one instead.
The surrogate code points U+D800 to U+DFFF are valid code points but are not Unicode scalar values. This commit makes the error message more accurately reflect what is actually allowed in `\u` escape sequences.
From https://www.unicode.org/versions/Unicode15.0.0/ch03.pdf:
> D71 High-surrogate code point: A Unicode code point in the range U+D800 to U+DBFF.
> D73 Low-surrogate code point: A Unicode code point in the range U+DC00 to U+DFFF.
>
> 3.9 Unicode Encoding Forms
> D76 Unicode scalar value: Any Unicode code point except high-surrogate and low-surrogate code points.
Related: #20270
A node may be freed during the execution of this loop, causing there to
be a parent reference to a nonexistent node. Without this assignment,
this would lead to the map entry containing stale data. By assigning
none, the child node with the bad parent pointer will be harmlessly
omitted from the tree.
Closes#20262
These instructions are not emitted by AstGen. They also would have no
effect even if they did appear in ZIR: the Sema handling for these
instructions creates a Decl which the name strategy is applied to, and
proceeds to never use it. This pointless CPU heater is now gone, saving
2 ZIR tags in the process.
Andrew Kelley