[lldb][TypeSystemClang] Unconditionally set access control to AS_public (#182956)
This patch removes all our manual adjustments to the access control
specifiers of Clang decls we create from DWARF.
This has led to occasional subtle bugs in the past (the latest being
https://github.com/llvm/llvm-project/issues/171913) and it's ultimately
redundant because Clang already has provisions for LLDB to bypass access
control for C++ and Objective-C. Access control doesn't affect name
lookup so really we're doing a lot of bookkeeping for not much benefit.
The only "feature" that relied on this was that `type lookup <foo>`
would print the access specifier in the output structure layout. I'm not
convinced that's worth keeping the infrastructure in place for (but
happy to be convinced otherwise).
I'd rather lean fully into the Clang access control bypass instead.
Note, i still kept the `AccessType` parameters to the various
`TypeSystemClang` APIs to reduce the size of the diff. A follow-up NFC
change will remove those parameters and adjust all the call-sites.
divert: Use a better source identifier for netisr_queue_src() calls
These opaque IDs are used by netisr to distribute work among threads.
The mapping function is simply SourceID % numthreads, so using socket
addresses as source IDs isn't going to distribute packets well due to
alignment.
Use the divert socket's generation number instead, as that suits this
purpose much better.
icmp6: clear csum_flags on mbuf reuse
When icmp6 sends an ICMPv6 message, it reuses the mbuf of the packet
that triggered the ICMPv6 message and prepends an IPv6 and ICMPv6
header. For a locally generated packet with checksum offloading, the
mbuf still has csum_flags set indicating that a SCTP/TCP/UDP checksum
has to be computed and inserted. Since this not the case anymore,
csum_flags need to be cleared.
PR: 293227
Reviewed by: kp, zlei, tuexen
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D55367
(cherry picked from commit ada4dc77577f7162353e8c2916ba5c258b6210f0)
[compiler-rt][ARM] Enable strict mode in divsf3/mulsf3 tests (#179918)
Commit 5efce7392f3f6cc added optimized AArch32 assembly versions of
mulsf3 and divsf3, with more thorough tests. The new tests included test
cases specific to Arm's particular NaN handling rules, which are
disabled on most platforms, but were intended to be enabled for Arm.
Unfortunately, they were not enabled under any circumstances, because I
made a mistake in `test/builtins/CMakeLists.txt`: the command-line `-D`
option that should have enabled them was added to the cflags list too
early, before the list was reinitialized from scratch. So it never ended
up on the command line.
Also, the test file mulsf3.S only even _tried_ to enable strict mode in
Thumb1, even though the Arm/Thumb2 implementation would also have met
its requirements.
Because the strict-mode tests weren't enabled, I didn't notice that they
would also have failed absolutely everything, because they checked the
[8 lines not shown]
Firewall: NAT: Merge npt_rule, onat_rule, snat_rule, dnat_rule into a single nat_rule template (#9855)
Most notable differences that are decided by the controller providing an "entrypoint" and "categoryKey" variable:
- controller name (entrypoint)
- category key (category vs categories)
Other subtle differences:
- enabled/disabled key (dnat is disabled)
- DNAT local port cannot do port ranges so the list_port_select_options reflect that
The functionality should be the same as before with less code as the same view template can be shared by all NAT controllers.
xkeyboard-config: update to 2.47.
# Layouts
## New
- Added the Slavistic Phonetic Alphabet variant for Polish
# Miscellaneous
## Breaking changes
- Made <ZEHA> behave like <FK24>
On Linux Kernel before v6.17, the scancode for F24 was bound to the otherwise
unused <ZEHA> keycode. v6.17 fixed this. To have a consistent behaviour across
kernel versions, make both <ZEHA> and <FK24> behave the same.
## New
[35 lines not shown]
libksba: updated to 1.6.8
Noteworthy changes in version 1.6.8 (2026-02-23)
* Fix double increment in DN parser while counting hexdigits.
* Fix a memory leak in the BER decoder's error handling.
* Fix an assertion failure in the OCSP code.
* Support SHA256 based CertIDs in OCSP.
* Use nonstring attribute for gcc-15.
* Remove remaining WindowsCE support.
SDL3: updated to 3.4.2
3.4.2
This is a stable bugfix release, with the following changes:
Enabled Vulkan support on OpenBSD
Don't include KHR_portability_enumeration by default on macOS
Added support for GPU ARGB1555 (B5G5R5A1_UNORM) textures with Direct3D11
Fixed D3D12 DSV creation for array/cube/cube-array depth textures
Added SDL_PROP_GPU_DEVICE_CREATE_METAL_ALLOW_MACFAMILY1_BOOLEAN to allow using the GPU API with older Mac hardware
Added SDL_HINT_OPENGL_FORCE_SRGB_FRAMEBUFFER to force specific sRGB behavior for OpenGL and OpenGL ES
Fixed long startup time on Windows when some non-compliant input devices are present
Fixed a crash at startup when the broken EZFRD64.DLL is present
Added support for the Razer Raiju V5 Pro
Fixed a divide by zero when using Nintendo Switch 2 controllers
Fixed hang sending output reports to the NVIDIA SHIELD Controller on macOS
Fixed various controllers showing up twice on macOS
Fixed handling GameCube adapters in PC mode on Linux and macOS
[7 lines not shown]
[mlir][SPIRV] Add sub-element-byte lowering support for atomic_rmw ori/andi ops (#179831)
When the memref element type (e.g., i8) is narrower than the SPIR-V
storage type (e.g., i32 on Vulkan), ori and andi can be lowered with a
single wide atomic instruction because OR-with-0 and AND-with-1 are
identity operations.
The revision follows `IntStoreOpPattern` to compute offsets/sizes via
`adjustAccessChainForBitwidth` method and `getOffsetForBitwidth` method.
Additionally, it handles the returned value (which is the old value by
definition), which is different from `IntStoreOpPattern`. E.g., the
check of `spirv::Capability::Kernel` is the same.
https://github.com/llvm/llvm-project/blob/07ebb18e07fb9e009b1f738d6214a49c7bbe8fee/mlir/lib/Conversion/MemRefToSPIRV/MemRefToSPIRV.cpp#L847-L867
There are refactoring opportunities and it is not performed within the
revision because the current implementation is already complicated. The
refactoring can be happenned in a follow-up with its own patch, so
[6 lines not shown]
