I think this is working correctly. Without also removing sse2 from the
feature set, sse gets added back into the set because sse2 is part of
the x86_64 baseline (which is the cpu provided) and sse2 depends on sse.
in favor of CPU features. Also rearrange the `std.Target`
data structure.
* note: `@import("builtin")` was already deprecated in favor of
`@import("std").builtin`.
* `std.builtin.arch` is now deprecated in favor of
`std.builtin.cpu.arch`.
* `std.Target.CpuFeatures.Cpu` is now `std.Target.Cpu.Model`.
* `std.Target.CpuFeatures` is now `std.Target.Cpu`.
* `std.Target` no longer has an `arch` field. Instead it has a
`cpu` field, which has `arch`, `model`, and `features`.
* `std.Target` no longer has a `cpu_features` field.
* `std.Target.Arch` is moved to `std.Target.Cpu.Arch` and
it is an enum instead of a tagged union.
* `std.Target.parseOs` is moved to `std.Target.Os.parse`.
* `std.Target.parseAbi` is moved to `std.Target.Abi.parse`.
* `std.Target.parseArchSub` is only for arch now and moved
to `std.Target.Cpu.Arch.parse`.
* `std.Target.parse` is improved to accept CPU name and features.
* `std.Target.Arch.getBaselineCpuFeatures` is moved to
`std.Target.Cpu.baseline`.
* `std.Target.allCpus` is renamed to `std.Target.allCpuModels`.
* `std.Target.defaultAbi` is moved to `std.Target.Abi.default`.
* Significant cleanup of aarch64 and arm CPU features, resulting in
the needed bit count for cpu feature set going from 174 to 138.
* Add `std.Target.Cpu.Feature.Set.addFeatureSet` for merging
feature sets together.
`-target-feature` and `-target-cpu` are removed in favor of
`-mcpu`, to conform to established conventions, and it gains
additional power to support cpu features. The syntax is:
-mcpu=name+on1+on2-off1-off2
closes#4261
* remove "cpu features" that are actually just processors
* rename `v8` to `v8a`. this matches the corresponding
change to target/aarch64.zig
* rename types in preparation for removing sub-architecture
from `std.Target`.
I have other files changed in my dirty working tree, but about to make
some changes to arm.zig that I don't want batched with this commit.
Some C compilers, such as Clang, are known to rely on
argv[0] to find the path to their own executable,
without even bothering to resolve PATH. This results
in the message:
error: unable to execute command: Executable "" doesn't exist!
So we tell ChildProcess to expand argv[0] to the absolute path
to give them a helping hand.
* libc_installation.cpp is deleted.
src-self-hosted/libc_installation.zig is now used for both stage1 and
stage2 compilers.
* (breaking) move `std.fs.File.access` to `std.fs.Dir.access`. The API
now encourages use with an open directory handle.
* Add `std.os.faccessat` and related functions.
* Deprecate the "C" suffix naming convention for null-terminated
parameters. "C" should be used when it is related to libc. However
null-terminated parameters often have to do with the native system
ABI rather than libc. "Z" suffix is the new convention. For example,
`std.os.openC` is deprecated in favor of `std.os.openZ`.
* Add `std.mem.dupeZ` for using an allocator to copy memory and add a
null terminator.
* Remove dead struct field `std.ChildProcess.llnode`.
* Introduce `std.event.Batch`. This API allows expressing concurrency
without forcing code to be async. It requires no Allocator and does
not introduce any failure conditions. However it is not thread-safe.
* There is now an ongoing experiment to transition away from
`std.event.Group` in favor of `std.event.Batch`.
* `std.os.execvpeC` calls `getenvZ` rather than `getenv`. This is
slightly more efficient on most systems, and works around a
limitation of `getenv` lack of integration with libc.
* (breaking) `std.os.AccessError` gains `FileBusy`, `SymLinkLoop`, and
`ReadOnlyFileSystem`. Previously these error codes were all reported
as `PermissionDenied`.
* Add `std.Target.isDragonFlyBSD`.
* stage2: access to the windows_sdk functions is done with a manually
maintained .zig binding file instead of `@cImport`.
* Update src-self-hosted/libc_installation.zig with all the
improvements that stage1 has seen to src/libc_installation.cpp until
now. In addition, it now takes advantage of Batch so that evented I/O
mode takes advantage of concurrency, but it still works in blocking
I/O mode, which is how it is used in stage1.
and fix larger-than-one-byte sentinels when being freed
Thank you to João Pedro for identifying both problems and
providing example code to solve them.
closes#4413
1. behavior tests with --test-evented-io
2. std lib tests with --test-evented-io
3. fuzz test evented I/O a bit, make it robust
4. make sure it works on all platforms (kqueue, Windows IOCP,
epoll/other)
5. restart efforts on self-hosted
* `zig test` gainst `--test-evented-io` parameter and gains the ability
to seamlessly run async tests.
* `std.ChildProcess` opens its child process pipe with O_NONBLOCK when
using evented I/O
* `std.io.getStdErr()` gives a File that is blocking even in evented
I/O mode.
* Delete `std.event.fs`. The functionality is now merged into `std.fs`
and async file system access (using a dedicated thread) is
automatically handled.
* `std.fs.File` can be configured to specify whether its handle is
expected to block, and whether that is OK to block even when in
async I/O mode. This makes async I/O work correctly for e.g. the
file system as well as network.
* `std.fs.File` has some deprecated functions removed.
* Missing readv,writev,pread,pwrite,preadv,pwritev functions are added
to `std.os` and `std.fs.File`. They are all integrated with async
I/O.
* `std.fs.Watch` is still bit rotted and needs to be audited in light
of the new async/await syntax.
* `std.io.OutStream` integrates with async I/O
* linked list nodes in the std lib have default `null` values for
`prev` and `next`.
* Windows async I/O integration is enabled for reading/writing file
handles.
* Added `std.os.mode_t`. Integer sizes need to be audited.
* Fixed#4403 which was causing compiler to crash.
This is working towards:
./zig test ../test/stage1/behavior.zig --test-evented-io
Which does not successfully build yet. I'd like to enable behavioral
tests and std lib tests with --test-evented-io in the test matrix in the
future, to prevent regressions.
Clean up the code a bit and introduce a few checks meant to avoid
overshooting the end of the frame chain.
The code is now stable enough not to cause panics during the call frame
walking.
I do not see many cases of constant pointers to arrays in the stdlib.
In fact, this makes the code run a little faster, probably because Zig
automatically converts to pointers where it makes sense.
This is a translation of the [official reference implementation][1] with
few other changes. The bad news is that the reference implementation is
designed for simplicity and not speed, so there's a lot of room for
performance improvement. The good news is that, according to the crypto
benchmark, the implementation is still fast relative to the other
hashing algorithms:
```
md5: 430 MiB/s
sha1: 386 MiB/s
sha256: 191 MiB/s
sha512: 275 MiB/s
sha3-256: 233 MiB/s
sha3-512: 137 MiB/s
blake2s: 464 MiB/s
blake2b: 526 MiB/s
blake3: 576 MiB/s
poly1305: 1479 MiB/s
hmac-md5: 653 MiB/s
hmac-sha1: 553 MiB/s
hmac-sha256: 222 MiB/s
x25519: 8685 exchanges/s
```
[1]: https://github.com/BLAKE3-team/BLAKE3
- Strange memory corruption issues occur when allocated memory is passed to the builder and it is `defer`'d and freed
- Instead, `dupe` the string as is done in other handlers, this fixes the issue
* Let's consolidate the special-cased DWARF interpreter for OSX with the
general purpose one
* Drop the assumption that all the debug data is contained in a single
contiguous slice of memory. This is a good news for freestanding
targets and paves the way for supporting compressed debug sections.
Let's always subtract 1 from the return address so that we're sure to be
inside the callee.
Fixes some edge case where the stack trace skipped the first entry.
in stack tracing code, the idea was to detect the tty settings at the
top of the stack and pass the information down. somewhere along the way
this got changed so that setTtyColor was assuming the global stderr_file
was related to the output stream the stack trace was being printed to.
now, tty_color is changed to tty_config, and it is an enum rather than a
bool, telling how tty colors are expected to be handled. windows is
still incorrectly looking at stderr_file.
These were never working with native CPU features. In this branch,
we fix native CPU features not being enabled on Windows, and regress
f128 language features. In the llvm10 branch, all this is fixed,
and the tests are re-enabled.
Previously it was a tagged union which was one of:
* baseline
* a specific CPU
* a set of features
Now, it's possible to have a CPU but also modify the CPU's feature set
on top of that. This is closer to what LLVM does.
This is more correct because Zig's notion of CPUs (and LLVM's) is not
exact CPU models. For example "skylake" is not one very specific model;
there are several different pieces of hardware that match "skylake" that
have different feature sets enabled.
comment from this commit reproduced here:
I have observed the CPU name reported by LLVM being incorrect. On
the SourceHut build services, LLVM 9.0 reports the CPU as "athlon-xp",
which is a 32-bit CPU, even though the system is 64-bit and the reported
CPU features include, among other things, +64bit.
So the strategy taken here is that we observe both reported CPU, and the
reported CPU features. The features are trusted more; but if the features
match exactly the features of the reported CPU, then we trust the reported CPU.
use @fieldParentPtr to access your context fields, which lie if you
struct that contains a rb.Tree member (without a pointer).
Also simplifies the init() function so rb.Tree can be initialized in a single line,
without having to use "undefined".
Use a struct as second parameter to be future proof (and also allows to
specify default values for the parameters)
Closes#2679 as it was just a matter of a few lines of code.
Fixes#2379
= Overlong (non-shortest) sequences
UTF-8's unique encoding scheme allows for some Unicode codepoints
to be represented in multiple ways. For any of these characters,
the spec forbids all but the shortest form. These disallowed longer
sequences are called "overlong". As an interesting side effect of
this rule, the bytes C0 and C1 never appear in valid UTF-8.
= Codepoint range
UTF-8 disallows representation of codepoints beyond U+10FFFF,
which is the highest character which can be encoded in UTF-16.
Because a 4-byte sequence is capable of resulting in such characters,
they must be explicitly rejected. This rule also has an interesting
side effect, which is that bytes F5 to FF never appear.
= References
Detecting an overlong version of a codepoint could get gnarly, but
luckily The Unicode Consortium did the hard work by creating this
handy table of valid byte sequences:
https://unicode.org/versions/corrigendum1.html
I thought this mapped nicely to the parser's state machine, so I
rearranged the relevant states to make use of it.
LemonBoy
Andrew Kelley
Bas
daurnimator
Noam Preil
Vexu
xackus
Felix (xq) Queißner
data-man
Benjamin Feng
vegecode
Jared Miller
pwzk
Rocknest
nofmal
Michaël Larouche
Jay Petacat
frmdstryr
meme
Shawn Landden
Valentin Anger
Michael Dusan
Nathan Michaels
Layne Gustafson
Sebastian
Hersh Krishna
Jonathan Marler
Ryan Liptak
David Cao
mogud
emekoi
hryx
Timon Kruiper