[orc-rt] Make noDispatch test helper fail in -Asserts builds. (#209493)
noDispatch guards Sessions that must never dispatch a wrapper call, but
it did so with assert(false), which compiles out under NDEBUG.
Replace the assert with ADD_FAILURE(), which records a failure in every
build mode, and then complete the call via its Return continuation with
an out-of-band error. Completing the call means a caller awaiting the
result unblocks and fails too, rather than hanging, even when the
dispatch arrives on a non-test thread where ADD_FAILURE() alone may not
be observed.
Make ios_base::xalloc non-atomic with LIBCXX_ENABLE_THREADS=OFF. (#208356)
762b77a moved the definition of "xindex" out of the header, and in the
process dropped the _LIBCPP_HAS_THREADS check. Re-add the check to
maintain the status quo.
The discussion on https://github.com/llvm/llvm-project/pull/198994
indicates it's not clear whether LIBCXX_ENABLE_THREADS=OFF is actually
supposed to mean single-threaded. But it clearly does in practice:
atomic_support.h uses non-atomic ops when threads are disabled, and a
few other APIs have explicit non-atomic fallback paths.
My team ran into this trying to run libc++ tests for a RISC-V core
without the "a" extension.
[libc++] Compute a confidence interval in compare-benchmarks (#208090)
When comparing benchmark results with more than one sample per
benchmark, compute a confidence interval and flag rows that are
statistically significant. This should make the A/B comparison PR job
more robust to noise and easier to rely on. After this change, output
for a multi-sample run looks like:
```
Benchmark Baseline Candidate Difference % Difference Significant? 95% C.I. of %diff
------------------------------ ---------- ----------- ------------ -------------- -------------- -------------------
std::any_of(list<int>)/32 39.92 39.22 -0.70 -1.75% [-6.5%, +1.6%]
std::any_of(list<int>)/32768 54071.34 65395.51 11324.17 20.94% [-2.8%, +34.5%]
std::any_of(list<int>)/50 67.39 69.08 1.69 2.51% x [+0.2%, +4.7%]
std::any_of(list<int>)/8 7.21 6.46 -0.75 -10.40% x [-25.0%, -0.7%]
std::any_of(list<int>)/8192 21745.58 22299.32 553.74 2.55% [-20.3%, +38.4%]
std::any_of(vector<int>)/32 24.21 14.61 -9.60 -39.65% x [-41.2%, -38.4%]
std::any_of(vector<int>)/32768 24365.14 12498.21 -11866.93 -48.70% x [-48.9%, -48.6%]
Geomean 324.15 247.83 -76.32 -23.54%
[16 lines not shown]
[SSAF] Add EntitySourceLocationsSummary and JSON format (#208841)
Adds a per-entity TU-level summary recording the canonical (file, line,
column) of each declaration registered against an entity. The data feeds
a follow-on whole-program analysis that groups entities sharing a
declaration source-location into equivalence classes.
Assisted-By: Claude Opus 4.7
libzfs: don't abort receiving a raw encrypted send that carries holds
A raw send that gathers holds but not properties (zfs send -w -h,
without -p or -R) produces a compound stream whose per-filesystem
nvlist has no "props" entry. recv_fix_encryption_hierarchy() looked
that entry up with fnvlist_lookup_nvlist(), which aborts the process
when the key is missing, so receiving such a stream of an encrypted
dataset crashed with a failed VERIFY0() after the data had already
been received. Release builds abort the same way, since the VERIFY
family is always compiled in.
Look "props" up tolerantly and skip the keylocation fixup when it is
absent: a holds-only raw send sends no properties, and the raw
receive has already established a usable keylocation. The
FORCE_NEW_KEY and FORCE_INHERIT fixups, which do not need
properties, still run.
A new rsend test sends an encrypted dataset with -w -h, both a full
and an incremental stream, and confirms the receive succeeds with
[6 lines not shown]
[lldb-dap][test] Fix stackTrace test in symlink environment (#209595)
This test (edited in #209236) fails when run in an environment where
source files are symlinks. Using `realpath` breaks that, as we use the
path in assertions later. The var is already constructed as `source_file
= self.getSourcePath("main.c")` which should be sufficient for
`_RecurseSource()` to work.
Rate limit Direct I/O verify zevents
Each vdev initializes a vdev_dio_verify_rl rate limiter (governed by
zfs_dio_write_verify_events_per_second), but
zio_dio_chksum_verify_error_report() never consults it, so
dio_verify_rd and dio_verify_wr zevents are posted with no rate
limiting. A workload that repeatedly trips the Direct I/O verify can
therefore produce an unbounded flood of zevents.
Gate both ereport posts through zfs_ratelimit(&vd->vdev_dio_verify_rl),
as is already done for the other per-vdev ereports (checksum, delay,
deadman). The vs_dio_verify_errors vdev stat still increments on every
event, so the true count remains observable via zpool status -d.
The dio_write_verify test checks on every iteration that a
dio_verify_wr zevent was posted. With rate limiting now in effect the
shared limiter window is exhausted after the first iteration, so later
iterations observe zero events and the test fails. Raise
zfs_dio_write_verify_events_per_second for the duration of that test
[5 lines not shown]
