- x86_64: Implement @cVaStart for Win64
- x86_64: Implement @cVaArg for Win64
- x86_64: Duplicate floating point register args equivalent integer registers when calling variadic functions on Win64
- tests: Enable var_args tests for the self-hosted backend on windows
- tests: Add var_args test for floating point arguments
This problem also affected determining if an expression became multiline
as that depends on if the line is overindented. As such,
`becomesMultilineExpr` has been replaced by `rendersMultiline` which
constructs a temporary writer which returns `error.WriteFailed` when
newlines are written. This new approach also has the advantage of being
more maintainable.
This was especially bad as it could crash or duplicate them due to
them being moved around "zig fmt: on/off".
As a bonus this fixes a crash from reordering at the start of the file.
Previously, the comments would be lost with the colons.
This required a substantial rewrite of renderAsm to determine how many
colons should be rendered.
- PEG / Parser Changes
All the changes made here are to places where the PEG was more
permissive than the parser. Changes to the parser make it more
permissive and changes to the PEG make it more strict. When choosing
between these two options for discrepancies, I opted for the choice
that was more natural and increased code readability.
Changes to the Parser
* Tuple types can now be `inline` and `extern` (e.g. `extern struct`).
* Break labels are now only consumed if both the colon and identifier
are present instead of failing if there is only a colon.
* Labeled blocks are no longer parsed in PrimaryExpr (so they are now
allowed to have CurlySuffixExpr) as in the PEG.
* While expressions can now be grouped on the same line.
* Added distinction in error messages for "a multiline string literal"
so places where only single string literals are allowed do not give
"expected 'a string literal', found 'a string literal'".
Changes to the PEG
* Made it so extern functions cannot have a body
* Made it so ... can be only the last function argument
* Made it so many item pointers can't have bit alignment
* Made it so asm inputs / outputs can not be multiline string literals
* Added distinction between block-level statements and regular
statements
-- Pointer Qualifier Order
The PEG allowed for duplicated qualifiers, which the parser did not.
The simplest fix for this was to make each be allowed zero or one times
which required giving them a order similar to how FnProto already
works. The chosen order is the same as used by zig fmt. The parser
still accepts them in any order similar to functions.
-- Backtracking
Made it so several places could not backtrack in the PEG. A common
pattern for this was (A / !A).
--- !ExprSuffix
Expressions ending with expressions now have !ExprSuffix after.
This change prevents expressions such as `if (a) T else U{}` being be
parsable as `(if (a) T else U){}`. It also stops some backtracking,
take for example:
`if (a) for (b) |c| d else |e| f`
It may seem at first that the else clause belongs to the `for`, however
it actually belongs to the `if` because for else-clauses cannot have a
payload. This is fixed by a new `KEYWORD_else / !KEYWORD_else`, however
this alone does not fix more complex cases such as:
`if (a) for (b) |c| d() else |e| f`
The PEG would first attempt to parse it as expected but fail due to the
new guard. It will then backtrack to
`if (a) (for (b) |c| d)() else |e| f`
which is surprising but avoids the new gaurd. So, !ExprSuffix is
required to disallow this type of backtracking.
--- !LabelableExpr
For identifiers, excluding labels is necessary despite ordered choice
due to pointer bit alignment. For example `*align(a : b: for (c) e) T`
could backtrack to `*align(a : b : (for (c) e)) T`.
--- !SinglePtrTypeStart
Prevents expressions like `break * break` which is parsed as
`break (*break)` backtracking to `(break) * (break)`
--- !BlockExpr
Prevents expressions like `test { {} = a; }` being backtracked to and
parsed as `test { ({} = a); }` (the parenthesis are just for
demonstration, that expression is not legal either)
--- !ExprStatement
In addition to splitting up block level statements, statements that are
also parsable as expressions are now part of ExprStatement to disallow
backtracking.
This generates zig ASTs from `testing.Smith` and is based off the
langref's PEG.
The choice to not build the Ast while generating and instead parsing it
afterwards makes the smith more versatile by not being tied to a single
implementation at a cost of efficiency.
Additionally, a new function `boolWeighted` was added to `Smith` due to
its frequent use in `AstSmith`.
This prevents a race between `alloc` and `free` where T1 receives memory
from `alloc` that is semantically about to be freed by T2 and still being
accessed, but the `free` is already visible to T1. Using acquire-release
here guarantees that any `free` is only published after all accesses to
the memory being freed have already happened.
Co-authored-by: Jacob Young <amazingjacob@gmail.com>
This prevents a race between `alloc` and `free` where T1 receives memory
from `alloc` that is semantically about to be freed by T2 and still being
accessed, but the `free` is already visible to T1. Using acquire-release
here guarantees that any `free` is only published after all accesses to
the memory being freed have already happened.
Co-authored-by: Jacob Young <amazingjacob@gmail.com>
This reverts commit 589bcb2544.
The scenario presented in the reverted commit cannot actually happen.
Even if there are two contiguous arena nodes N1 and N2 and the `end_index`
of N1 points to somewhere in N2, a `resize` can never lead to an increase
of the `end_index` of N1 since it checks whether it's `<= size` first.
A `resize`/`free` *can* decrease `end_index`, but even if it is wrongly
assumed that some allocation that belongs to N2 actually belongs to N1
based on the `end_index` of N1, it can only ever be decreased to the start
of the buffer of N2. That's because a valid allocation of N2 logically
cannot be at any lower address than N2 itself. And any point still in N2
can never also be in N1, so there's no danger of overwriting any other
allocations of N1.
Currently the only function that handles sentinel terminated slices
properly is free. All uses of mem.sliceAsBytes() in the allocator
interface lack proper handling of a possible sentinel.
This commit changes the Allocator interface to use @ptrCast() plus
the new mem.absorbSentinel() instead.
Reported-by: David Vanderson <david.vanderson@gmail.com>
References: https://github.com/ziglang/zig/pull/19984
References: https://github.com/ziglang/zig/pull/23020
This will allow replacing (currently buggy) mem.sliceAsBytes() usage in
the mem.Allocator implementation with, for example:
const bytes: []u8 = @constCast(@ptrCast(mem.absorbSentinel(allocation)));
References: https://github.com/ziglang/zig/pull/22706
Address two separate but related issues:
- Return value of `RtlQueryPerformanceFrequency` was used inconsistently; it
returns a nonzero value to indicate success.
- `timeoutToWindowsInterval` wasn't converting absolute deadlines back to the
Windows epoch before passing them to the system, which meant that values (in
the Unix epoch) were always in the distant past, so sleeps would return
immediately.
Fixes#31653
Some initial work towards https://codeberg.org/ziglang/zig/issues/31414.
Conclusion from this: Only x86-freebsd, x86-haiku, and x86-illumos remain time32
and are currently unfixable. I don't think the upstreams for any of these
targets actually care about them anymore (probably why they weren't migrated to
time64), so this is not a particularly big concern.
I split UTIME constants out from timespec because they were causing unreasonable
code duplication by being there.
I understand the temptation to exploit page size knowledge to make this function
faster, but I don't think this code can ever be compatible with any reasonable
set of pointer provenance/aliasing rules. At the very least, I don't believe it
is compatible with LLVM's.
closes https://github.com/ziglang/zig/issues/23184
The first issue is that when len(Sn) >= 128,
we perform Sn xor D instead of the Sn xorend D
that is specified in RFC 5297.
The second issue is that we truncate the Sn
if it is larger than 4096 bytes, which could
lead to collisions between inputs. We solve
this by absoring the Sn into the CMAC state
perform the last 16 bytes, xoring those 16
bytes with D as described in the first issue,
and then updating and squeezing the CMAC.
As established in 048e38624e and d70bd0b37e, mutexes should use a strong
cmpxchg when attempting to lock to guarantee that they actually succeed
if they aren't locked yet.
Also deletes an unused near-duplicate of `mutexLock()`.
The `cmpxchgWeak` in `setIpcFile` could lead to the IPC file not being set
even though there's still a slot available because one or more slots were
spuriously skipped.
The `cmpxcheWeak` in `serialize` could lead to an unused IPC slot not
being locked and used even though it could be.
Having `std.Io.Uring` contain OpenError error set
allows handling of OperationUnsupported specifically for `.openat`,
while avoiding propagating this error to the more general
`File.OpenError`.
This more specific subset also eliminated 2 unreachable prongs that
previously inherited from `File.OpenError`.
Added comments when handling OperationUnsupported, making it clear it is
an unexpected error when TMPFILE bit is not set.
At smaller workloads the overhead of setting up a new `std.Io.Threaded`
for every run to reset thread-local state becomes more noticeable, so this
commit also switches from thread-local storage to a shared atomic variable
for keeping track of the most recent allocation. This has the side-effect
of simplifying the overall implementation a bit.
`resolveAddresses` now also works if some calls to `getDwarfForAddress`
fail with `error.MissingDebugInfo`; the affected source location is set
to `.invalid`.
This makes fuzzing work with `ReleaseSafe` for Mach-O.
- plain old data ftw
- 177K -> 151K
- data bypasses Sema
This change is not really important but it was nice to explore best
practices for data like this.
When I measured building the compiler, I found no statistically
significant difference in compilation time.
Alex Rønne Petersen