| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
Fix `takeDelimiter` and `takeDelimiterExclusive` tossing too many bytes
(#25132)
Also add/improve test coverage for all delimiter and sentinel methods,
update usages of `takeDelimiterExclusive` to not rely on the fixed bug,
tweak a handful of doc comments, and slightly simplify some logic.
I have not fixed #24950 in this commit because I am a little less
certain about the appropriate solution there.
Resolves: #25132
Co-authored-by: Andrew Kelley <andrew@ziglang.org>
|
|
Related to 1d764c1fdf04829cec5974d82cec901825a80e49
Test case provided by:
Co-authored-by: Kendall Condon <goon.pri.low@gmail.com>
|
|
* File.Writer.seekBy passed wrong offset to setPosAdjustingBuffer.
* File.Writer.sendFile incorrectly used non-logical position.
Related to 1d764c1fdf04829cec5974d82cec901825a80e49
Test case provided by:
Co-authored-by: Kendall Condon <goon.pri.low@gmail.com>
|
|
return 0
Previously, the logic in peekDelimiterInclusive (when the delimiter was not found in the existing buffer) used the `n` returned from `r.vtable.stream` as the length of the slice to check, but it's valid for `vtable.stream` implementations to return 0 if they wrote to the buffer instead of `w`. In that scenario, the `indexOfScalarPos` would be given a 0-length slice so it would never be able to find the delimiter.
This commit changes the logic to assume that `r.vtable.stream` can both:
- return 0, and
- modify seek/end (i.e. it's also valid for a `vtable.stream` implementation to rebase)
Also introduces `std.testing.ReaderIndirect` which helps in being able to test against Reader implementations that return 0 from `stream`/`readVec`
Fixes #25428
|
|
|
|
`std.debug`: MIPS and PowerPC unwind support + some other stuff
|
|
`std.debug`: be more resilient in the face of unsupported registers
|
|
This reverts commit 27aba2d776caf59bb6569934626af587fdba9c75.
I'd like to review this contribution more carefully, particularly with
the alternate implementation that is also open as a pull request
(#25109).
Reopens #25093
|
|
|
|
|
|
`findScalarPos` might do repetitive work, even if using simd. For
example, when searching the string `/abcde/fghijk/lm` for the character
`/`, a 16-byte wide search would yield `1000001000000100` but would only
count the first `1` and re-search the remaining of the string.
When testing locally, the difference was quite significative:
```
count scalar
5737 iterations 522.83us per iterations
0 bytes per iteration
worst: 2370us median: 512us stddev: 107.64us
count v2
38333 iterations 78.03us per iterations
0 bytes per iteration
worst: 713us median: 76us stddev: 10.62us
count scalar v2
99565 iterations 29.80us per iterations
0 bytes per iteration
worst: 41us median: 29us stddev: 1.04us
```
Note that `count v2` is a simpler string search, similar to the
remaining version of the simd approach:
```
pub fn countV2(comptime T: type, haystack: []const T, needle: T) usize {
const n = haystack.len;
if (n < 1) return 0;
var count: usize = 0;
for (haystack[0..n]) |item| {
count += @intFromBool(item == needle);
}
return count;
}
```
Which implies the compiler yields some optimized code for a simpler loop
that is more performant than the `findScalarPos`-based approach, hence
the usage of iterative approach for the remaining of the haystack.
Co-authored-by: StAlKeR7779 <stalkek7779@yandex.ru>
|
|
We know that these are unsupported and irrelevant for unwinding, so don't fail
the unwind attempt trying to read/write them for no ultimate purpose.
|
|
This does not hold on PowerPC.
|
|
of invalid
|
|
Let's for the moment assume that compilers haven't lost the plot.
Fingers crossed.
|
|
32-63 conflict with the floating point registers. 64 and 65 are used for the
ac0 hi/lo registers.
|
|
It's free real estate, as it turns out.
|
|
32-63 conflict with the floating point registers. 64 is the Alternate Frame
Return Column.
|
|
32-63 conflict with the floating point registers.
|
|
|
|
|
|
We care about the hardware here, not the ABI.
|
|
95bdb0c1c65c128923ffac3f4be6b4619eb4a54b
|
|
Fixes stack traces missing a frame depending on inlining decisions.
ref https://github.com/ziglang/zig/issues/25418
|
|
|
|
|
|
If the ABI requires a backchain pointer, FP unwinding is always possible, safe,
and fast, so there's really no reason not to use it.
|
|
Closes #25486
|
|
For unwinding purposes, we don't care about unsupported registers. Yet because
we added these rules to the cache entry, we'd later try to evaluate them and
thus fail the unwind attempt for no good reason. They'd also take up cache rule
slots that would be better spent on actually relevant registers.
Note that any attempt to read unsupported registers during unwinding will still
fail the unwind attempt as expected.
|
|
Support generating import libraries from mingw .def files without LLVM
|
|
`std.debug`: add unwind support for `hexagon-linux`
|
|
|
|
`std.zig.system`: add OS checks for QEMU in `getExternalExecutor()`
|
|
* ELF v1 on powerpc64 is only barely kept on life support in a couple of Linux
distros. I don't anticipate that this will last much longer.
* Most of the Linux world has moved to powerpc64le which requires ELF v2.
* Some Linux distros have even started supporting powerpc64 with ELF v2.
* The BSD world has long since moved to ELF v2.
* We have no actual linking support for ELF v1.
* ELF v1 had confused DWARF register mappings which is becoming a problem in
our DWARF code in std.debug.
It's clear that ELF v1 is on its way out, and we never fully supported it
anyway. So let's not waste any time or energy on it going forward.
closes #5927
|
|
FreeBSD doesn't support the same number of platforms as Linux, and even then,
only has usermode emulation for a subset of its supported platforms.
NetBSD's usermode emulation support is apparently just broken at the moment.
|
|
|
|
|
|
|
|
std.fs.Dir: Add `walkSelectively` to provide more control over directory walking
|
|
|
|
The DWARF code can't handle these yet.
ref https://github.com/ziglang/zig/issues/25447
|
|
|
|
|
|
std.debug: Add unwind support for serenity
|
|
|
|
|
