Fix for a clang-repl crash when passing non-existent file to --Xcc (#225861)
Problem: When clang-repl fails to initialize because an --Xcc file does
not exist, Interpreter::create() destroys the partially initialized
Interpreter. Its destructor unconditionally calls FinalizeAction(),
which invokes FrontendAction::EndSourceFile() without a registered
CompilerInstance and triggers an assertion.
Fix: Track whether interpreter initialization completed successfully and
only finalize the frontend action for successfully initialized
interpreters.
Test: Add a regression test covering a nonexistent --Xcc file.
This change resolves https://github.com/llvm/llvm-project/issues/225429
Assisted by gpt-5.6-luna
---------
Co-authored-by: Anutosh Bhat <andersonbhat491 at gmail.com>
Do not write multiple assignment of the same value to multiple cmmu registers
as nested assignment in a single statement.
This used to work in the gcc 2 days, but from gcc 3 onwards, because these
registers are declared volatile, this caused register reloads to propagate
the assignment value.
This had been noticed and fixed in arch/luna88k/luna88k/machdep.c 1.135, but
the similar constructs in this file were missed.
Noticed by tsutsuii at netbsd
Do not limit kernel-mode cmmu fault handling to segment and page faults,
there could be write protection faults as well.
The CMU Mach code did not have such a restriction, it had been added by
Nivas while doing the original mvme88k port.
The logic is now the same for kernel and userland.
Noticed by tsutsui at netbsd.
Revert "[clang][bytecode] Stop relying on `CheckEvaluationResult()` (… (#226637)
…#186045)"
This reverts commit 55b498466a7b2620d09fcdf1b2300f71a35f6d8b.
This breaks two msan builders and reproducing the failure locally takes
forever.
Revert "[clang][OpenMP] Only accept char strings in the message clause" (#226636)
Reverts llvm/llvm-project#226080
The newly added test error_message.c is failing on the PS4 bot
https://lab.llvm.org/buildbot/#/builders/144/builds/66294
[libc++][NFC] Avoid empty namespace in internal headers of `<ranges>` (#226034)
...in pre-C++20/23 modes. This follows up
0c94a978df783bd67535350eac84088fc482716a and fixes more complaints from
clang-tidy checks in CI.
pkg: minor fixes to the vec iterators
Clear the caller"s pointer when the list is empty, as the previous
implementation did, and declare the index before the statements.
Handle two causes of the panic "lfs_ifile: looping". Repurpose the lfs_iflock
to be locked with RW_WRITER while the segment lock is held, preventing
updates to the Ifile while its blocks are being gathered; and allow more
iterations than 10 before panicking, since we might need to rewrite the
entire segment table one block per iteration. Issue uncovered in the course
of PR kern/60746.
Rename pwenc_secret_matches unit test to a unique basename
## Problem
The new `pytest/unit/utils/test_pwenc.py` shares its basename with the existing `tests/unit/test_pwenc.py`. The unit test run collects both trees in one pytest session, so collection aborts with "import file mismatch".
## Solution
Renamed the new file to `test_pwenc_secret_matches.py`, which also matches what it actually tests.
cpdup: Don't pass an uninitialized pointer to getgroups(0, ...).
getmygroups() passed *gidlist to the size-only getgroups() query
before it was initialized. The list argument is ignored when the
size is 0, so pass NULL instead.
Bug: #3425
libevtr: Fix off-by-one in string namespace indexing.
evtr_dump_string() indexed evtr->strings[ns] although the array is
sized EVTR_NS_MAX - 1. The namespace IDs are EVTR_NS_PATH=1,
EVTR_NS_FUNC=2 and EVTR_NS_DSTR=3, so ns == 3 runs one past the array
and aliases the following union member (fmts): the dynamic-string
namespace and the format-string table then share a hashtable, and the
table allocated for that slot by evtr_open_write() leaks.
The read side already uses maps[ns - 1], so make the write side
consistent and only allocate/free the EVTR_NS_MAX - 1 entries.
Also reject ns == 0 in evtr_load_string(); the old check let it
through and maps[ns - 1] would read before the array on corrupt input.
Bug: #3424
editors/openoffice-devel: Update to a new snapshot
Update openoffice-devel to a newer snapshot
Change the splash screen to say OpenOffice 5.
MFH: 2026Q3
(cherry picked from commit 1abe115b569e34b6197b26206cc461e38f28f52d)
editors/openoffice-devel: Upgrade to a new snapshot
Upgrade to a new snapshot of the upstream AOO42X branch.
Switch from system textproc/libtextcat to bundled libtextcat.
The system version probably never worked properly because it
lacks UTF-8 support, whereas the bundled version has been patched
to support UTF-8. Longer term, libtextcat should be replaced
by libexttextcat.
Disable WIKI_PUBLISHER and mark BROKEN. It relies on
apache-commons-httpclient which has an open MITM CVE. It should
be upgraded to Apache HttpComponents, but that requires a newer
java.
Disable bridgetest on i386 due to a uno core dump in testtools.
Removed old code optimization tweak that is probably left over
from when we used the buggy -Os compiler optimization flag.
[5 lines not shown]
editors/openoffice-devel: switch to upstream trunk
Switch to following the upstream trunk branch. The AOO42X is likely a
dead end, and the next major release will propably be 5.0.0.
(cherry picked from commit b630d5755e107f881a4c840c8165ead7c1a49670)
Accept stats_ex on zpool query vdevs
## Problem
truenas_pylibzfs added an extended mode to `ZFSPool.iostat()` that fills a new `stats_ex` field on every vdev. `status()` returns the same vdev struct, so its vdevs now carry `stats_ex` too (always `None` there). `zpool.query` passes those vdev dicts straight into `ZPoolVdev`, which forbids unknown keys, so every topology query failed with `extra_forbidden`. This broke `pool.create` at its change event and aborted the api, cloud, stig, directory services and sharing test suites at pool setup.
## Solution
Added a nullable `stats_ex` field to `ZPoolVdev` in both the v26 and v27 API models, the same way `path` was added ahead of its pylibzfs change. It defaults to `None`, so it works with both old and new pylibzfs.
cpdup: Don't pass an uninitialized pointer to getgroups(0, ...).
getmygroups() passed *gidlist to the size-only getgroups() query
before it was initialized. The list argument is ignored when the
size is 0, so pass NULL instead.
Bug: #3425
libevtr: Fix off-by-one in string namespace indexing.
evtr_dump_string() indexed evtr->strings[ns] although the array is
sized EVTR_NS_MAX - 1. The namespace IDs are EVTR_NS_PATH=1,
EVTR_NS_FUNC=2 and EVTR_NS_DSTR=3, so ns == 3 runs one past the array
and aliases the following union member (fmts): the dynamic-string
namespace and the format-string table then share a hashtable, and the
table allocated for that slot by evtr_open_write() leaks.
The read side already uses maps[ns - 1], so make the write side
consistent and only allocate/free the EVTR_NS_MAX - 1 entries.
Also reject ns == 0 in evtr_load_string(); the old check let it
through and maps[ns - 1] would read before the array on corrupt input.
Bug: #3424
fsck_msdosfs: fix head bitmap over-allocation on 32-bit platforms
bitmap_ctor() computed the allocation size as
roundup2(bits, LONG_BIT) / (LONG_BIT / 8)
The dividend is a count of bits, so converting it to bytes requires
dividing by 8 (bits per byte), not by LONG_BIT / 8 (bytes per long).
The two divisors happen to coincide on LP64, but on ILP32 platforms
the head bitmap was allocated at twice the required size; for a
FAT32 file system with close to 2^28 clusters, that is 64 MiB instead
of 32 MiB.
The extra half of the allocation was never accessed, so there is no
functional change other than the reduced memory footprint.
MFC after: 3 days
Pull Request: https://github.com/freebsd/freebsd-src/pull/2440
fsck_msdosfs: fix head bitmap over-allocation on 32-bit platforms
bitmap_ctor() computed the allocation size as
roundup2(bits, LONG_BIT) / (LONG_BIT / 8)
The dividend is a count of bits, so converting it to bytes requires
dividing by 8 (bits per byte), not by LONG_BIT / 8 (bytes per long).
The two divisors happen to coincide on LP64, but on ILP32 platforms
the head bitmap was allocated at twice the required size; for a
FAT32 file system with close to 2^28 clusters, that is 64 MiB instead
of 32 MiB.
The extra half of the allocation was never accessed, so there is no
functional change other than the reduced memory footprint.
MFC after: 3 days
Pull Request: https://github.com/freebsd/freebsd-src/pull/2440
