Note that the `_ = Address` statements in tests previously were a nop,
and now actually check that the type is valid. However, on WASI, the
type is *not* valid.
Adds a missing call to addLazyPathDependenciesOnly in
std.Build.Module.addCSourceFiles. Also fixes an issue in
std.Build.Step.WriteFile where it wasn't updating all the GeneratedFile
instances for every directory. To fix the second issue, I removed
all the GeneratedFile instances and now all files/directories reference
the steps main GeneratedFile via sub paths.
This was the only kind of error which was raised in pipeToFileSystem and
not added to Diagnostics.
Shell tar silently ignores paths which are stripped out when used with
`--strip-components` switch. This enables that same behavior, errors
will be collected in diagnostics but caller is free to ignore that type
of diagnostics errors.
Enables use case where caller knows structure of the tar file and want
to extract only some deeply nested folders ignoring upper files/folders.
Fixes: #17620 by giving caller options:
- not provide diagnostic and get errors
- provide diagnostics and analyze errors
- provide diagnostics and ignore errors
The eventfd system call and dup3 library call have been available
since FreeBSD 13 and 10 respectively, and are thus available in
all [FreeBSD releases not deemed EOL](<https://endoflife.date/freebsd>)
The lack of these were discovered when porting a terminal emulator
to FreeBSD. It would be nice to have them included in Zig's stdlib.
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.
This reverts commit d7daf7c203f583ed440efc68df6ee690ee8f8f32.
This is no longer needed with the LLVM 18 upgrade, and it was breaking PIE.
Closes#20306.
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`.
