[LoongArch][NFC] Replace manual v2i128 check with MVT::v2i128 (#241726)
Now that v2i128 is a legal MVT, the manual v2i128 check and the
associated stale comment are no longer needed. Compare against
MVT::v2i128 directly instead.
[libc][test] Fix dangling CString paths in copy_file_range_test (#241787)
Fixes the `aarch64` / overlay failure in
`libc.test.src.unistd.copy_file_range_test` introduced by #240018.
### Root Cause
1. `libc_make_test_file_path(...)` returns an owning `CString`
(non-copyable, non-movable). Storing it into `const char *in_path` /
`out_path` in `SetUp()` destroyed the temporary `CString` immediately,
leaving dangling pointers for `open()` and `unlink()` and causing
`ENOENT` in `SetUp()` (cascading into `EBADF` in `CopyNoOffsets` and
`CopyWithOffsets`).
2. `LlvmLibcCopyFileRangeTest::SetUp()` and `TearDown()` overrode
`ErrnoCheckingTest::SetUp()` / `TearDown()` without invoking the base
class methods.
### Changes
- Initialize `in_path` and `out_path` directly as fixture members using
`decltype(libc_make_test_file_path(...))` so the `CString` objects stay
[8 lines not shown]
[flang] Fix incorrect reallocation for host-associated main-program coarrays #231233 (#233361)
This fix resolves the issue #231233 involving incorrect reallocation of
a coarray when it is accessed via host association in a nested
procedure.
---------
Co-authored-by: Dan Bonachea <dobonachea at lbl.gov>
[Hexagon] Add local VTCM frames for HLX objects (#241650)
Move local HLX objects to a separate VTCM frame, address them through
VSP, and allocate and release the frame with vallocframe and
vdeallocframe.
Co-authored-by: Yashas Andaluri <yandalur at qti.qualcomm.com>
[flang][Semantics] Adding check integer kind on STAT= specifier #230463 (#231103)
This PR adds a pedantic warning to check whether the specified STAT is
an integer of at least 16-bit because
flang currently silently accepts 8-bit integers to `STAT=`: and F2023
9.7.4 says:
> R946 _stat-variable_ is _scalar-int-variable_
>
> A stat-variable should have a decimal exponent range of at least four;
otherwise the
> processor-dependent error code might not be representable in the
variable.
[SPIRV] Keep source location on OpAsmCallINTEL
insertInlineAsmProcess builds OpAsmCallINTEL with a MachineIRBuilder
whose debug location is empty.
The call therefore had no location, so the NonSemantic
debug handler emitted no debug line information.
sysutils/libmbus: [NEW PORT] Meter-bus library and utility programs
The Meter-Bus is a standard for reading out meter data from
electricity meters, heat meters, gas meters, etc. The M-bus
standard deals with both the electrical signals on the M-Bus,
and the protocol and data format used in transmissions on
the M-Bus. The role of libmbus is to decode/encode M-bus
data, and to handle the communication with M-Bus devices.
WWW: https://github.com/rscada/libmbus/
PR: 298095
Co-authored by: alven@
[Clang][NFC] Re-enable consumed analysis test for chained logical OR (#240849)
Re-enable the three-way logical OR test in `testComplexConditionals1` by
removing its `#if 0` guard and stale FIXME. The operands start in the
unknown consumed state. Keep all six existing expected warnings in the
true and false branches unchanged.
Prepared with assistance from Codex.
[Clang][NFC] Re-enable local-class static member diagnostic test (#240834)
Re-enable the local-class static data member example in
`clang/test/SemaTemplate/instantiate-static-local.cpp`. Keep its
existing `expected-error {{static}}`, remove the `#if 0` guard and stale
crash FIXME, and remove the conflicting `expected-no-diagnostics`
marker.
The crash was fixed by e2def106757534b07a2d3ff15ddd48e14b69a66d
(#182707). A targeted AArch64 snapshot search followed by native X86
assertions-on builds confirms the boundary: the parent
c1c4a5a870eb668fec480771c4d002e17362ed18 crashes in
`LocalInstantiationScope::findInstantiationOf` on both attempts, while
the fix emits only the expected illegal-static-member diagnostic and
exits normally on both attempts.
Prepared with assistance from Codex.
NAS-145210 / 27.0.0 / Keep encryption keys loaded on zfs.resource.unmount by default (by Qubad786) (#20200)
## Problem
`zfs.resource.unmount` documents `unload_encryption_key` as defaulting
to `False`, but `unmount_impl` only passed it to truenas_pylibzfs when
it was `True`. truenas_pylibzfs defaults it to `True`, so every unmount
of an encryption root unloaded its key, and a recursive unmount did the
same for every encryption root below it. A later `zfs.resource.mount`
then failed with "encryption key not loaded" (e.g. ix-apps after a
docker stop, or a container dataset left behind by migration).
## Solution
Always pass `unload_encryption_key` to truenas_pylibzfs so the caller's
value is honoured. The lock path already passes `True` explicitly, so
its behaviour is unchanged. Added an integration test that recursively
unmounts a parent with an encrypted child and checks the child's key
survives and it can be mounted again.
Original PR: https://github.com/truenas/middleware/pull/20189
Co-authored-by: M. Rehan <mrehanlm93 at gmail.com>
NAS-145210 / 27.1.0 / Keep encryption keys loaded on zfs.resource.unmount by default (by Qubad786) (#20201)
## Problem
`zfs.resource.unmount` documents `unload_encryption_key` as defaulting
to `False`, but `unmount_impl` only passed it to truenas_pylibzfs when
it was `True`. truenas_pylibzfs defaults it to `True`, so every unmount
of an encryption root unloaded its key, and a recursive unmount did the
same for every encryption root below it. A later `zfs.resource.mount`
then failed with "encryption key not loaded" (e.g. ix-apps after a
docker stop, or a container dataset left behind by migration).
## Solution
Always pass `unload_encryption_key` to truenas_pylibzfs so the caller's
value is honoured. The lock path already passes `True` explicitly, so
its behaviour is unchanged. Added an integration test that recursively
unmounts a parent with an encrypted child and checks the child's key
survives and it can be mounted again.
Original PR: https://github.com/truenas/middleware/pull/20189
Co-authored-by: M. Rehan <mrehanlm93 at gmail.com>
NAS-145153 / 27.1.0 / Fail graceful VM and container stop when the guest keeps running (by Qubad786) (#20202)
## Problem
A graceful `vm.stop` / `container.stop` (no `force`, no
`force_after_timeout`, the API default) waited `shutdown_timeout` and
then reported SUCCESS even when the guest ignored the shutdown request
and was still running. The UI showed the guest as stopped and a graceful
container restart then failed on start with "already started". A
suspended VM was also left suspended with a successful job, even with
`force_after_timeout`, because the post-stop check only looked for
`RUNNING`.
## Solution
After the shutdown request, both stop paths check the state again. If
the guest has not stopped, it is powered off when `force_after_timeout`
is set; otherwise the job fails with an ETIMEDOUT `CallError` saying it
did not stop within the timeout. A suspended VM is resumed before the
shutdown request so the guest can act on it, and library errors (e.g.
stopping a guest that is not running) are raised as `CallError` like
[5 lines not shown]
NAS-145155 / 28.0.0-BETA.1 / Harden container image pull (#20188)
## Problem
Pulling a container image leaked raw `requests` errors, had no timeout
on the tarball download so a stalled stream hung forever and never
checked the published sha256. The pull was a sync job, so it could only
stop at its own abort checks, and `container.create` wasn't abortable at
all. Two concurrent pulls of the same uncached image could also destroy
each other's in-progress dataset through the orphan cleanup.
## Solution
- **Readable registry errors**: registry index failures (connection,
HTTP status, timeout, bad JSON) are raised as `CallError('Failed to
query container image registry: ...')`.
- **aiohttp with timeouts**: the registry fetch and tarball download use
aiohttp with connect and per-read timeouts of `INTERNET_TIMEOUT` and no
total limit, so a stall fails the pull instead of hanging. `trust_env`
is set so the `http(s)_proxy` environment is still honoured, as it was
with `requests`.
[22 lines not shown]
[CIR] Use `cir.vec.fcmp` op for AArch64 builtins (#241404)
I've been splitting integer and floating comparisons and stumbled upon
these.
claude updated the test.
