* `RunStep` moved to lib/std/build/run.zig and gains ability to compare
output and exit code against expected values. Multiple redundant
locations in the test harness code are replaced to use `RunStep`.
* `WriteFileStep` moved to lib/std/build/write_file.zig and gains
ability to write more than one file into the cache directory, for
when the files need to be relative to each other. This makes
usage of `WriteFileStep` no longer problematic when parallelizing
zig build.
* Added `CheckFileStep`, which can be used to validate that the output
of another step produced a valid file. Multiple redundant locations
in the test harness code are replaced to use `CheckFileStep`.
* Added `TranslateCStep`. This exposes `zig translate-c` to the build
system, which is likely to be rarely useful by most Zig users;
however Zig's own test suite uses it both for translate-c tests and
for run-translated-c tests.
* Refactored ad-hoc code to handle source files coming from multiple
kinds of sources, into `std.build.FileSource`.
* Added `std.build.Builder.addExecutableFromWriteFileStep`.
* Added `std.build.Builder.addExecutableSource`.
* Added `std.build.Builder.addWriteFiles`.
* Added `std.build.Builder.addTranslateC`.
* Added `std.build.LibExeObjStep.addCSourceFileSource`.
* Added `std.build.LibExeObjStep.addAssemblyFileFromWriteFileStep`.
* Added `std.build.LibExeObjStep.addAssemblyFileSource`.
* Exposed `std.fs.base64_encoder`.
* Implements #3768. This is a sweeping breaking change that requires
many (trivial) edits to Zig source code. Array values no longer
coerced to slices; however one may use `&` to obtain a reference to
an array value, which may then be coerced to a slice.
* Adds `IrInstruction::dump`, for debugging purposes. It's useful to
call to inspect the instruction when debugging Zig IR.
* Fixes bugs with result location semantics. See the new behavior test
cases, and compile error test cases.
* Fixes bugs with `@typeInfo` not properly resolving const values.
* Behavior tests are passing but std lib tests are not yet. There
is more work to do before merging this branch.
The actual desired access mask in this case seems quite confusing and badly documented. The previous combination of `GENERIC_READ` and `SYNCHRONIZE` seems both illegal and redundant according to the [`ntifs.h` documentation](https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntcreatefile), which specifies that `GENERIC_READ` should not be used for directories and includes `SYNCHRONIZE`. `winnt.h` contains a number of relevant-sounding flags such as `FILE_ADD_FILE`, `FILE_ADD_SUBDIRECTORY`, and `FILE_DELETE_CHILD` that do not show up in documentation at all. These are equal in value to file-specific flags that are documented as flags you should not specify when opening a directory.
The Windows-inspired nomenclature of "List" and "Traverse" was chosen over POSIX-style "Read" and "Path" (from `O_PATH`) for clarity. Using "Path" makes it look like the function is manipulating strings, and the generic "Read" ending isn't useful when there is no generic read method. Even in implementation details, `read` is never used.
Actual exploitation of the difference between the two functions will come in a later commit.
this also deletes C string literals from the language, and then makes
the std lib changes and compiler changes necessary to get the behavior
tests and std lib tests passing again.
It had the downside of running all the comptime blocks and resolving
all the usingnamespaces of each system, when just trying to discover if
the current system is a particular one.
For Darwin, where it's nice to use `std.Target.current.isDarwin()`, this
demonstrates the utility that #425 would provide.
* Added `std.c.unlinkat` and `std.os.unlinkat`.
* Removed `std.fs.MAX_BUF_BYTES` (this declaration never made it to
master branch)
* Added `std.fs.Dir.deleteTree` to be used on an open directory handle.
* `std.fs.deleteTree` has better behavior for both relative and
absolute paths. For absolute paths, it opens the base directory
and uses that handle for subsequent operations. For relative paths,
it does a similar strategy, using the cwd handle.
* The error set of `std.fs.deleteTree` is improved to no longer have
these possible errors:
- OutOfMemory
- FileTooBig
- IsDir
- DirNotEmpty
- PathAlreadyExists
- NoSpaceLeft
* Added `std.fs.Dir.posix_cwd` which is a statically initialized
directory representing the current working directory.
* The error set of `std.Dir.open` is improved to no longer have these
possible errors:
- FileTooBig
- IsDir
- NoSpaceLeft
- PathAlreadyExists
- OutOfMemory
* Added more alternative functions to `std.fs` for when the path
parameter is a null terminated string. This can sometimes be more
effecient on systems which have an ABI based on null terminated
strings.
* Added `std.fs.Dir.openDir`, `std.fs.Dir.deleteFile`, and
`std.fs.Dir.deleteDir` which all operate on an open directory handle.
* `std.fs.Walker.Entry` now has a `dir` field, which can be used to do
operations directly on `std.fs.Walker.Entry.basename`, avoiding
`error.NameTooLong` for deeply nested paths.
* Added more docs to `std.os.OpenError`
This commit does the POSIX components for these changes. I plan to
follow up shortly with a commit for Windows.
* `std.os.execve` had the wrong name; it should have been
`std.os.execvpe`. This is now corrected.
* introduce `std.os.execveC` which does not look at PATH, and uses
null terminated parameters, matching POSIX ABIs. It does not
require an allocator.
* fix typo nonsense doc comment in `std.fs.MAX_PATH_BYTES`.
* introduce `std.os.execvpeC`, which is like `execvpe` except it
uses null terminated parameters, matching POSIX ABIs, and thus
does not require an allocator.
* `std.os.execvpe` implementation is reworked to only convert
parameters and then delegate to `std.os.execvpeC`.
* `std.os.execvpeC` improved to handle `ENOTDIR`. See #3415
Andrew Kelley
Jonathan S
dimenus
Tse
stratact