[clang][bytecode] Fix `MemberExpr`s with a static member (#193902)
We need logic to load from the reference pointer, similar to the one we
have for regular `DeclRefExpr`s.
[AAEval] Print ModRefInfo for atomic operations (#193935)
Print ModRefInfo for fence, atomicrmw, etc. Also for atomic
load and store, as these may have additional effects beyond
what is implied by the simple alias result.
[LangRef] Specify that syncscopes can affect the monotonic modification order
If a target specifies that atomics with mismatching syncscopes appear
non-atomic to each other, there is no point in requiring them to be ordered in
the monotonic modification order. Notably, the [AMDGPU target user
guide](https://llvm.org/docs/AMDGPUUsage.html#memory-scopes) has specified
syncscopes to relax the modification order for years.
So far, I haven't found an example where this less constrained ordering would
be observable (at least with the AMDGPU inclusive scope rules). Whenever a load
would be able to see two monotonic stores with non-inclusive scope, that's
considered a data race (i.e., the load would return `undef`), so it cannot be
used to observe the order of the stores.
[AMDGPUUsage] Specify what one-as syncscopes do
This matches the currently implemented and (as far as I could determine)
intended semantics of these syncscopes.
The sync scope table is unchanged except for removing its indentation;
otherwise it would be rendered as part of the preceding note.
[LangRef][AMDGPU] Specify that syncscope can cause atomic operations to race
Targets should be able to specify that the syncscope of atomic operations
influences whether they participate in data races with each other.
For example, in AMDGPU, we want (and already implement) the load in the
following case to be in a data race (i.e., return `undef` according to the
current definition), because there is an atomic store with workgroup syncscope
executing in a different workgroup:
```
; workgroup 0:
store atomic i32 1, ptr %p syncscope("workgroup") monotonic, align 4
; workgroup 1:
store atomic i32 2, ptr %p syncscope("workgroup") monotonic, align 4
load atomic i32, ptr %p syncscope("workgroup") monotonic, align 4
```
[3 lines not shown]
[LangRef] Allow monotonic & seq_cst accesses to inter-operate with other accesses (#189014)
Currently, the LangRef says that atomic operations (which includes `unordered`
operations, which don't participate in the monotonic modification order) must
read a value from the modification order of monotonic operations.
In the following example, this means that the load does not have a store it
could read from, because all stores it may see do not participate in the
monotonic modification order:
```
; thread 0:
store atomic i32 1, ptr %p unordered, align 4
; thread 1:
store atomic i32 2, ptr %p unordered, align 4
load atomic i32, ptr %p unordered, align 4
```
[19 lines not shown]
py-simplejson: updated to 4.1.0
Version 4.1.0 released 2026-04-22
* The C extension now accelerates encoding when ``indent=`` is set.
Previously the encoder fell back to the pure-Python implementation
whenever a non-None ``indent`` was passed; now the C encoder emits
the newline-plus-indent prefix, the level-aware item separator, and
the closing indent directly. A representative nested-dict workload
benchmarks about 4-5x faster end-to-end, and the ``indent=0`` and
empty-container edge cases continue to match the Python output
byte-for-byte.
* The C extension now emits PEP 678 ``exc.add_note()`` annotations on
serialization failures, matching the pure-Python encoder. A chained
error on ``{'a': [1, object(), 3]}`` produces the same three notes
(``when serializing object object``, ``when serializing list item 1``,
``when serializing dict item 'a'``) whether the speedups are loaded
or not, so the add_note assertions in ``test_errors.py`` no longer
need ``indent=2`` to force the Python path.
py-scrapy: updated to 2.15.1
Scrapy 2.15.1 (2026-04-23)
Bug fixes
- Sharing of the SSL context between multiple connections, introduced in
Scrapy 2.15.0, is reverted as it caused problems and wasn't actually
needed.
- Fixed :meth:`scrapy.settings.BaseSettings.getwithbase` failing on keys with
dots that aren't import names. It now works the way it worked before Scrapy
2.15.0, without trying to match class objects and import path. A separate
method,
:func:`~scrapy.settings.BaseSettings.get_component_priority_dict_with_base`,
was added that does that, and it is now used for :ref:`component priority
dictionaries <component-priority-dictionaries>`.
- Documentation rendering improvements.
[lldb][Linux] Read memory protection keys for memory regions (#182246)
Memory protection keys
(https://docs.kernel.org/core-api/protection-keys.html) are implemented
using two things:
* A key value attached to each page table entry.
* A set of permissions stored somewhere else (in a register on AArch64
and X86), which is indexed into by that protection key.
So far I have updated LLDB to show the permissions part on AArch64 Linux
by reading the por register. Now I am adding the ability to see which
key each memory region is using.
```
(lldb) memory region --all
[0x0000000000000000-0x000aaaae3b140000) ---
[0x000aaaae3b140000-0x000aaaae3b150000) r-x /tmp/test_lldb/linux/aarch64/permission_overlay/2/TestAArch64LinuxPOE/a.out PT_LOAD[0]
protection key: 0
[0x000aaaae3b150000-0x000aaaae3b160000) rw- /tmp/test_lldb/linux/aarch64/permission_overlay/2/TestAArch64LinuxPOE/a.out
[27 lines not shown]
py-faker: updated to 40.15.0
40.15.0 - 2026-04-17
* Add job providers for `ar_DZ` and `fr_DZ` locales
* Add company providers for `ar_DZ` and `fr_DZ` locales
* Add geo providers for `ar_DZ` and `fr_DZ` locales
* Add currency providers for `ar_DZ` and `fr_DZ` locales
* Add `date_time` provider for `ar_DZ` locale
* Add ssn providers for `ar_DZ` and `fr_DZ` locales
py-greenlet: updated to 3.4.0
3.4.0 (2026-04-08)
- Publish binary wheels for RiscV 64.
- Fix multiple rare crash paths during interpreter shutdown.
Note that this now relies on the ``atexit`` module, and introduces
subtle API changes during interpreter shutdown (for example,
``getcurrent`` is no longer available once the ``atexit`` callback fires).
- Address the results of an automated code audit performed by
Daniel Diniz. This includes several minor correctness changes that
theoretically could have been crashing bugs, but typically only in
very rare circumstances.
- Fix several race conditions that could arise in free-threaded
builds when using greenlet objects from multiple threads, some of
which could lead to assertion failures or interpreter crashes.
opensc: updated to 0.27.1
New in 0.27.1; 2026-03-31
* Bugfix release to fix up infrastructure issues.
New in 0.27.0; 2026-03-30
Security
* CVE-2025-13763: Several uses of potentially uninitialized memory detected by fuzzers
* CVE-2025-49010: Possible write beyond buffer bounds during processing of GET RESPONSE APDU
* CVE-2025-66215: Possible write beyond buffer bounds in oberthur driver
* CVE-2025-66038: Possible read beyond buffer bounds when parsing historical bytes in PIV driver
* CVE-2025-66037: Possible buffer overrun while parsing SPKI
* More low-severity data handling issues when parsing profile configuration
General improvements
* Added support for PKCS#11 3.2 in tools and pkcs11-spy and p11test
* Added support for Ed448, X448 mechanisms and improve support for
[52 lines not shown]
py-tox: updated to 4.53.0
Features - 4.53.0
TOML env_list now accepts bare range dicts ({ prefix = "3.", start = 12, stop = 14 }) and bare labeled dicts ({ ecosystem = ["oci", "python"] }) as top-level items, removing the { product = [...] } wrapper when there is only a single factor group
Bug fixes - 4.53.0
Nesting a range or labeled dict inside a product factor-group list now raises a clear error pointing at the un-nesting fix, instead of silently producing a malformed environment name
py-virtualenv: updated to 21.2.4
Bugfixes - 21.2.4
Security hardening: validate each entry of a seed wheel archive before extracting it so a tampered wheel cannot escape the app-data image directory via an absolute path or .. traversal.
Security hardening: verify the SHA-256 of every bundled seed wheel when it is loaded so a corrupted or tampered file on disk fails loud instead of being handed to pip. The hash table is generated alongside BUNDLE_SUPPORT by tasks/upgrade_wheels.py.
Security hardening: validate the distribution name and version specifier passed to pip download when acquiring a seed wheel so extras, pip flags, or shell metacharacters cannot be smuggled into the subprocess command line.
Security hardening: replace the string-prefix containment check in virtualenv.util.zipapp with Path.relative_to so the zipapp extraction helpers refuse any path that does not resolve under the archive root.
Security hardening: do not silently fall back to an unverified HTTPS context when the periodic update request to PyPI fails TLS verification. The returned metadata drives which wheel version virtualenv considers “up to date”, so accepting an unverified response lets a network-level attacker suppress security updates. Set VIRTUALENV_PERIODIC_UPDATE_INSECURE=1 to restore the previous behavior on hosts with broken trust stores.
