zig fmt previously would write a temp file, and then either rename it
into place if necessary, or unlink it if nothing was changed. Now zig
fmt renders into a memory buffer, and only writes the temp file and
renames it into place if anything changed.
Based on the performance testing I did this actually did not have much
of an impact, however it's likely that on other operating systems and
other hard drives this could make a big difference.
* `std.fs.Dir.Entry.Kind` is moved to `std.fs.File.Kind`
* `std.fs.File.Stat` gains the `kind` field, so performing a stat() on
a File now tells what kind of file it is. On Windows this only will
distinguish between directories and files.
* rework zig fmt logic so that in the case of opening a file and
discovering it to be a directory, it closes the file descriptor
before re-opening it with O_DIRECTORY, using fewer simultaneous open
file descriptors when walking a directory tree.
* rework zig fmt logic so that it pays attention to the kind of
directory entries, and when it sees a sub-directory it attempts to
open it as a directory rather than a file, reducing the number of
open() syscalls when walking a directory tree.
The original check for a directory was for the `readAllAlloc` so move the check from open to read. This in turn fixes the fmt step in the build script for directories.
One of the main motivating use cases for this language feature is
tracing/profiling tools, which expect null-terminated strings for these
values. Since the data is statically allocated, making them
additionally null-terminated comes at no cost.
This prevents the requirement of compile-time code to convert to
null-termination, which could increase the compilation time of
code with tracing enabled.
See #2029
std.log provides 8 log levels and corresponding logging functions. It
allows the user to override the logging "backend" by defining root.log
and to override the default log level by defining root.log_level.
Logging functions accept a scope parameter which allows the implementer
of the logging "backend" to filter logging by library as well as level.
Using the standardized syslog [1] log levels ensures that std.log will
be flexible enough to work for as many use-cases as possible. If we were
to stick with only 3/4 log levels, std.log would be insufficient for
large and/or complex projects such as a kernel or display server.
[1]: https://tools.ietf.org/html/rfc5424#section-6.2.1
Branch handling `*[N]T` to `E![]T` is already handled in a more complete
branch handling `*[N]T` to `[]T` *and* `*[N]T` to `E![]T` so it seems
safe to remove this one.
